[jira] [Updated] (NIFI-4765) SiteToSiteProvenanceReportingTask does not sent ROUTE events.

[Koji Kawamura (JIRA)]

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

Koji Kawamura updated NIFI-4765:

Priority: Major  (was: Blocker)

> SiteToSiteProvenanceReportingTask does not sent ROUTE events.
> -
>
> Key: NIFI-4765
> URL: https://issues.apache.org/jira/browse/NIFI-4765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Martin Mucha
>Assignee: Koji Kawamura
>Priority: Major
> Attachments: SiteToSiteProvenanceReportingTaskFail.xml, 
> generateInvalidJson
>
>
> I need to read JSON validation failures. ValidateRecord emits ROUTE events. I 
> can see such route events in data provenance tab. I tried to access them 
> using SiteToSiteProvenanceReportingTask. I can see receive/drop events coming 
> in and being logged via provided flow, but no ROUTE events. There is no 
> filtering in place defined on SiteToSiteProvenanceReportingTask.
> to reproduce: 
> 1. use provided template
> 2. use provided script to configure invokeScript processor (that one seems to 
> be buggy, and I wasn't able to reliably set script body in it, therefore I 
> used file)
> 3. if you invoke all processors, you should see validation failure being 
> logged, route provenance event emitted, but you won't find it arriving into 
> "provenance in".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (NIFI-4765) SiteToSiteProvenanceReportingTask does not sent ROUTE events.

[Koji Kawamura (JIRA)]

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

Koji Kawamura resolved NIFI-4765.
-
Resolution: Cannot Reproduce
  Assignee: Koji Kawamura

[~alfonz] Thanks for reporting the issue. However, I couldn't reproduce the 
reported behavior with the template and script you provided.

The script successfully emitted a ROUTE provenance event and it is properly 
reported by SiteToSiteProvenanceEvent as follows:

{code}
}, {
  "eventId" : "0102fa9d-6209-4806-9e1b-46530b254f05",
  "eventOrdinal" : 97,
  "eventType" : "ROUTE",
  "timestampMillis" : 1516086656542,
  "timestamp" : "2018-01-16T07:10:56.542Z",
  "durationMillis" : -1,
  "lineageStart" : 1516086652972,
  "details" : "Records in this FlowFile were invalid for the following reasons: 
The following 1 fields were missing: [/partyUID]",
  "componentId" : "ba3a1fab-8788-3ee1-e4fa-bf00c8dc3ad4",
  "componentType" : "ValidateRecord",
  "componentName" : "MockOfAvroValidation",
  "processGroupId" : "fdcbdff9-0160-1000-453f-17a8c8cef66f",
  "processGroupName" : "NIFI-4765",
  "entityId" : "cf465936-7c3c-4e1e-ac4b-bdece3d03447",
  "entityType" : "org.apache.nifi.flowfile.FlowFile",
  "entitySize" : 4,
  "updatedAttributes" : {
"path" : "./",
"mime.type" : "application/json",
"filename" : "23525023114493",
"uuid" : "cf465936-7c3c-4e1e-ac4b-bdece3d03447",
"record.count" : "1",
"schema.name" : "schemaMock"
  },
{code}

Please feel free to reopen this if there is any reproducing condition that I 
missed.

> SiteToSiteProvenanceReportingTask does not sent ROUTE events.
> -
>
> Key: NIFI-4765
> URL: https://issues.apache.org/jira/browse/NIFI-4765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Martin Mucha
>Assignee: Koji Kawamura
>Priority: Blocker
> Attachments: SiteToSiteProvenanceReportingTaskFail.xml, 
> generateInvalidJson
>
>
> I need to read JSON validation failures. ValidateRecord emits ROUTE events. I 
> can see such route events in data provenance tab. I tried to access them 
> using SiteToSiteProvenanceReportingTask. I can see receive/drop events coming 
> in and being logged via provided flow, but no ROUTE events. There is no 
> filtering in place defined on SiteToSiteProvenanceReportingTask.
> to reproduce: 
> 1. use provided template
> 2. use provided script to configure invokeScript processor (that one seems to 
> be buggy, and I wasn't able to reliably set script body in it, therefore I 
> used file)
> 3. if you invoke all processors, you should see validation failure being 
> logged, route provenance event emitted, but you won't find it arriving into 
> "provenance in".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2213: Update StandardOidcIdentityProvider.java

[Senthilannaswamy]

Github user Senthilannaswamy commented on the issue:

https://github.com/apache/nifi/pull/2213
  
@mcgilman
No I've not created any Jira for this issue. The underlying reason for the 
change was to handle the Optional tag for ClientAuthenticationMethod.


---

[jira] [Commented] (NIFI-4745) Emit validation failure description in attribute from ValidateRecord processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4745:
--

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/2384
  
Hi @martin-mucha Thanks for your first contribution! The PR is closed 
without being reviewed and I can't find other PRs created for NIFI-4745. Do you 
have a PR ready for being reviewed somewhere?

About your concern to add another argument to the completeFlowFile method 
which has already lots of arguments, I think that should be fine, since it's 
just a private method and the method is a good place to add new attribute 
values.

BTW, ValidateRecord can validate multiple Records within a single incoming 
FlowFile. Is it going to be sufficient to write validation result to a FlowFile 
attribute? Isn't it be more useful if we can write validation failure detail to 
the outgoing Records, so that each record can have its failure detail?



> Emit validation failure description in attribute from ValidateRecord processor
> --
>
> Key: NIFI-4745
> URL: https://issues.apache.org/jira/browse/NIFI-4745
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.5.0
>Reporter: Martin Mucha
>Priority: Minor
>
> We need to pass description of validation failure further in
> processing chain, and eventually pass it back to calling system.
> Therefore having failure description logged in logs and issued as provenance
> route event is not sufficient for us. 
> It should be easy to emit same data, which are being sent in provenance route 
> event, from ValidateRecord as new attribute.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2384: NIFI-4745 : configuration property allowing failure descri...

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/2384
  
Hi @martin-mucha Thanks for your first contribution! The PR is closed 
without being reviewed and I can't find other PRs created for NIFI-4745. Do you 
have a PR ready for being reviewed somewhere?

About your concern to add another argument to the completeFlowFile method 
which has already lots of arguments, I think that should be fine, since it's 
just a private method and the method is a good place to add new attribute 
values.

BTW, ValidateRecord can validate multiple Records within a single incoming 
FlowFile. Is it going to be sufficient to write validation result to a FlowFile 
attribute? Isn't it be more useful if we can write validation failure detail to 
the outgoing Records, so that each record can have its failure detail?



---

[jira] [Commented] (NIFIREG-77) Allow a user to see the changes created by the currently loaded version

[Danny Lane (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326671#comment-16326671
 ] 

Danny Lane commented on NIFIREG-77:
---

I've added a WIP commit here is anyone would like to offer feedback before I 
submit a PR?
https://github.com/dannylane/nifi-registry/commit/eeed846167dc90d983ea1d37d4149980b3057be2

I tried to go with the API returning the existing diff classes but each 
{{FlowDifference}} contains references to before/after versions of the 
components and they got serialized in the API response which I though was a bit 
much.
I added a couple of classes to the model module to act as the response form the 
API (they are essentially {{Dto}} s but I didn't use that naming convention as 
I didn't see it used in the registry project).

The behavior is very similar to how NiFi gathers it's changes for the 'Show 
Local Changes' functionality at the moment.

Happy to make changes if this is way off base...


> Allow a user to see the changes created by the currently loaded version
> ---
>
> Key: NIFIREG-77
> URL: https://issues.apache.org/jira/browse/NIFIREG-77
> Project: NiFi Registry
>  Issue Type: Improvement
>Affects Versions: 0.1.0
>Reporter: Joseph Percivall
>Priority: Critical
> Attachments: Suggestion for diff UX.png
>
>
> As a user, I would like to see the changes that are included in a particular 
> version. More specifically, if I'm on an old version and I upgrade to a 
> version written by someone else, I have no way to know what changes occurred 
> during that version upgrade.
> A simple solution would be to utilize the same logic which displays the 
> current differences between local and stored in the registry and use that to 
> show the differences between the current version N and version N-1. The user 
> could then change between versions to see the changes that happened as part 
> of that version.
> An even better solution (from a DFM perspective) would be to be able to see 
> the changes within any version (not just the most recent). That way a DFM 
> wouldn't have to stop the flow for an extended period of time to view the 
> changes/differences in different versions but I think that'd be more work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (NIFI-4779) Create SPARQL processor to extract data from RDF file formats

[Ben Schofield (JIRA)]

Ben Schofield created NIFI-4779:
---

 Summary: Create SPARQL processor to extract data from RDF file 
formats
 Key: NIFI-4779
 URL: https://issues.apache.org/jira/browse/NIFI-4779
 Project: Apache NiFi
  Issue Type: New Feature
  Components: Core Framework
Affects Versions: 1.4.0
Reporter: Ben Schofield


SPARQL is the query language for RDF data.  It allows data to be extracted from 
RDF files.  A new RDF processor should enable a SPARQL query to be applied 
against RDF data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (NIFI-4778) Create RDF processor for converting RDF files between file formats

[Ben Schofield (JIRA)]

Ben Schofield created NIFI-4778:
---

 Summary: Create RDF processor for converting RDF files between 
file formats
 Key: NIFI-4778
 URL: https://issues.apache.org/jira/browse/NIFI-4778
 Project: Apache NiFi
  Issue Type: New Feature
  Components: Core Framework
Affects Versions: 1.4.0
Reporter: Ben Schofield


RDF is a standard model for data interchange on the Web.  
[https://www.w3.org/RDF/]

There are multiple file formats defined for RDF data persistence and exchange. 

rdf/xml - [https://www.w3.org/TR/rdf-syntax-grammar/]

Turtle - [https://www.w3.org/TR/turtle/]

N Triples - [https://www.w3.org/TR/n-triples/]

There is value in a processor which can convert RDF data between the various 
standardized formats.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4424) org.apache.nifi.NiFi does not allow programmatic access to the NiFi engine

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4424:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2251
  
I don't see any breaking changes. 


> org.apache.nifi.NiFi does not allow programmatic access to the NiFi engine
> --
>
> Key: NIFI-4424
> URL: https://issues.apache.org/jira/browse/NIFI-4424
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Peter Horvath
>Priority: Major
>
> Class {{org.apache.nifi.NiFi}} was not designed with extensibility or 
> programmatic access in mind.
> This class is the entry point of the engine, however, the current 
> implementation does not allow
> a potential caller (e.g. an integration test harness) to bootstrap the engine 
> and then shut it down properly:
> The main method {{org.apache.nifi.NiFi#main}} simply logs any exception, 
> which is fine
> when started from the command line, however prevents programmatic usage and
> detecting error conditions (Exceptions) that would be essential to 
> programatically access 
> it from an integration test.
> The constructor {{org.apache.nifi.NiFi#NiFi}} registers an 
> {{UncaughtExceptionHandler}}, 
> a JVM {{Shutdown Hook}} and changes logging framework settings.
> *Please change this behaviour:*
> Expose *two* methods, one of which accepts the command line argument one 
> would pass
> to the NiFi process and another one, which allows the NiFiProperties object 
> to be passed.
> This method should return the {{NiFi}} object instance for further 
> programmatic access.
> The logic used to register {{UncaughtExceptionHandler}}, a JVM Shutdown Hook 
> and 
> changing logging framework settings should be extracted to a {{protected}} 
> *instance*
> method so that a client can override their behaviour with a NO-OP.
> A second class called e.g. {{org.apache.nifi.EmbeddedNiFi}} could be 
> introduced as
> a base class for this use-case, where the engine is started through the Java 
> API.
> *Please note these changes are baby-steps towards the implementation of a 
> NiFi integration test harness.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2251: NIFI-4424 org.apache.nifi.NiFi does not allow programmatic...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2251
  
I don't see any breaking changes. 


---

[jira] [Commented] (NIFI-4424) org.apache.nifi.NiFi does not allow programmatic access to the NiFi engine

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4424:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2251
  
This looks fine to me (have a full clean build w/contrib check running but 
i expect it will be fine).  Travis-CI would probably work fine now too given 
all the improvements that have been made.

I am fine with this change personally though.  @markap14  and @alopresto as 
people that have worked on code in here please take a look and see if there is 
anything of concern.  Otherwise either @patricker or i will merge.  Thanks


> org.apache.nifi.NiFi does not allow programmatic access to the NiFi engine
> --
>
> Key: NIFI-4424
> URL: https://issues.apache.org/jira/browse/NIFI-4424
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Peter Horvath
>Priority: Major
>
> Class {{org.apache.nifi.NiFi}} was not designed with extensibility or 
> programmatic access in mind.
> This class is the entry point of the engine, however, the current 
> implementation does not allow
> a potential caller (e.g. an integration test harness) to bootstrap the engine 
> and then shut it down properly:
> The main method {{org.apache.nifi.NiFi#main}} simply logs any exception, 
> which is fine
> when started from the command line, however prevents programmatic usage and
> detecting error conditions (Exceptions) that would be essential to 
> programatically access 
> it from an integration test.
> The constructor {{org.apache.nifi.NiFi#NiFi}} registers an 
> {{UncaughtExceptionHandler}}, 
> a JVM {{Shutdown Hook}} and changes logging framework settings.
> *Please change this behaviour:*
> Expose *two* methods, one of which accepts the command line argument one 
> would pass
> to the NiFi process and another one, which allows the NiFiProperties object 
> to be passed.
> This method should return the {{NiFi}} object instance for further 
> programmatic access.
> The logic used to register {{UncaughtExceptionHandler}}, a JVM Shutdown Hook 
> and 
> changing logging framework settings should be extracted to a {{protected}} 
> *instance*
> method so that a client can override their behaviour with a NO-OP.
> A second class called e.g. {{org.apache.nifi.EmbeddedNiFi}} could be 
> introduced as
> a base class for this use-case, where the engine is started through the Java 
> API.
> *Please note these changes are baby-steps towards the implementation of a 
> NiFi integration test harness.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2251: NIFI-4424 org.apache.nifi.NiFi does not allow programmatic...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/2251
  
This looks fine to me (have a full clean build w/contrib check running but 
i expect it will be fine).  Travis-CI would probably work fine now too given 
all the improvements that have been made.

I am fine with this change personally though.  @markap14  and @alopresto as 
people that have worked on code in here please take a look and see if there is 
anything of concern.  Otherwise either @patricker or i will merge.  Thanks


---

[jira] [Commented] (NIFI-4776) Test suite behavioral differences

[Marco Gaido (JIRA)]

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

Marco Gaido commented on NIFI-4776:
---

Hi [~nologic]! I can't find any processor which uses `asLong()` for a data 
size.  Might you please state exactly where this happens? Thanks.

> Test suite behavioral differences
> -
>
> Key: NIFI-4776
> URL: https://issues.apache.org/jira/browse/NIFI-4776
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mikhail Sosonkin
>Priority: Major
>
> I think there might a difference in behavior for how processor attributes are 
> evaluated in the test suite vs real execution. I'm not entirely sure if it is 
> an expected/acceptable behavior. It has to do with the DATA_SIZE_VALIDATOR. 
> Mine was defined as follows:
>  
>     public static final PropertyDescriptor MAX_ROW_SIZE = new 
> PropertyDescriptor
>         .Builder().name(BigQueryAttributes.MAX_ROW_SIZE_ATTR)
>         .displayName("Max row size")
>         .description(BigQueryAttributes.MAX_ROW_SIZE_DESC)
>         .required(true)
>         .defaultValue("1 MB")
>         .addValidator(StandardValidators.DATA_SIZE_VALIDATOR)
>         .build();
>  
> Then I would use it like this in the onTrigger method:
>  
>     final long max_row_size = context.getProperty(MAX_ROW_SIZE).asLong();
>  
> I used it this way based on the examples I've seen in the other processors. 
> In the runtime it seems to be working great and gives me the byte values. 
> However, in testing it would throw an exception because it would try to parse 
> "1 MB" (the default value) as an actual Long. Of course, if I just place a 
> long value (like 1024) it would not pass the validation function. So, I did a 
> more explicit "cast" using the asDataSize method:
>  
>     final long max_row_size = 
> context.getProperty(MAX_ROW_SIZE).asDataSize(DataUnit.B).longValue();
>  
> This solved my problems and makes the code a bit more explicit which is nice. 
> The annoying part is that the StandardProcessorTestRunner does not keep the 
> stacktrace from the exceptions generated in onTrigger of the processor 
> (StandardProcessorTestRunner:199)
>  
>    final Throwable thrown = future.get();
>  
> That is what caused confusion for me. I hadn't realized that the exception 
> was being thrown via my code. So, if anything the test suite needs to do a 
> better job at delivering stack traces for the exceptions to help with 
> debugging. Depending on what you decide, there might be two tasks here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

Attachment: 0012-get-schema-by-id-even-if-not-latest.patch

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0012-get-schema-by-id-even-if-not-latest.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

Attachment: (was: 0001-get-schema-subject-by-id.patch)

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0012-get-schema-by-id-even-if-not-latest.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4777:
--

GitHub user adfel70 opened a pull request:

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

NIFI-4777 get schema by id even if not latest

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

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

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

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


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

$ git pull https://github.com/adfel70/nifi NIFI-4777

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

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

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

This closes #2405


commit 87f318975c1b46302e809c467295ab17b90efda1
Author: Internet 
Date:   2018-01-15T12:34:41Z

get schema by id even if not latest




> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0001-get-schema-subject-by-id.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

External issue URL: https://github.com/apache/nifi/pull/2405  (was: 
https://github.com/apache/nifi/pull/2404)

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0001-get-schema-subject-by-id.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2405: NIFI-4777 get schema by id even if not latest

[adfel70]

GitHub user adfel70 opened a pull request:

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

NIFI-4777 get schema by id even if not latest

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

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

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

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


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

$ git pull https://github.com/adfel70/nifi NIFI-4777

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

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

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

This closes #2405


commit 87f318975c1b46302e809c467295ab17b90efda1
Author: Internet 
Date:   2018-01-15T12:34:41Z

get schema by id even if not latest




---

[jira] [Commented] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4777:
--

Github user adfel70 closed the pull request at:

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


> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0001-get-schema-subject-by-id.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2404: NIFI-4777 get schema subject by id

[adfel70]

Github user adfel70 closed the pull request at:

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


---

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

Attachment: 0001-get-schema-subject-by-id.patch

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0001-get-schema-subject-by-id.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

Status: Patch Available  (was: Open)

This patch is tested against rel/nifi-1.5.0

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
> Attachments: 0001-get-schema-subject-by-id.patch
>
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

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

AdFel updated NIFI-4777:

External issue URL: https://github.com/apache/nifi/pull/2404

> ConfluentSchemaRegistry Controller service fails to fetch schema if id not in 
> cache and schema is not latest
> 
>
> Key: NIFI-4777
> URL: https://issues.apache.org/jira/browse/NIFI-4777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: AdFel
>Priority: Major
>
> If the controller service was down and the schema was updated,
> the schema will not be found, even though it exists just because it is not 
> the latest version.
> This fix searches for uncached schemas through the registry's subjects to 
> figure out which version of the subject it was, even if it is not the latest 
> schema.
> This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2404: get schema subject by id

[adfel70]

GitHub user adfel70 opened a pull request:

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

get schema subject by id

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

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

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

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


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

$ git pull https://github.com/adfel70/nifi NIFI-4777_confluent_schema_id_fix

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

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

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

This closes #2404


commit 18b1c9965a1f31962815f3a63d90d1bbf8253a34
Author: Internet 
Date:   2018-01-15T11:35:43Z

get schema subject by id




---

[jira] [Created] (NIFI-4777) ConfluentSchemaRegistry Controller service fails to fetch schema if id not in cache and schema is not latest

[AdFel (JIRA)]

AdFel created NIFI-4777:
---

 Summary: ConfluentSchemaRegistry Controller service fails to fetch 
schema if id not in cache and schema is not latest
 Key: NIFI-4777
 URL: https://issues.apache.org/jira/browse/NIFI-4777
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: AdFel


If the controller service was down and the schema was updated,
the schema will not be found, even though it exists just because it is not the 
latest version.
This fix searches for uncached schemas through the registry's subjects to 
figure out which version of the subject it was, even if it is not the latest 
schema.

This patch is for version 1.5.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)