[jira] [Commented] (NIFI-6633) Allow user to copy a parameter context
[ https://issues.apache.org/jira/browse/NIFI-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110584#comment-17110584 ] Andrew Grande commented on NIFI-6633: - I don't think it's the use case I'm after here. A nifi cluster talking to both environments for sync, bridging, reconciliation purposes etc has a need to have multiple contexts. A developer experience would also call for a quick way to clone the context and experiment , as this entity is not necessarily versioned in the registry. > Allow user to copy a parameter context > -- > > Key: NIFI-6633 > URL: https://issues.apache.org/jira/browse/NIFI-6633 > Project: Apache NiFi > Issue Type: New Feature > Components: Core UI >Reporter: Rob Fellows >Priority: Major > > It would be nice to be able to copy/duplicate an existing parameter context. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-6633) Allow user to copy a parameter context
[ https://issues.apache.org/jira/browse/NIFI-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110575#comment-17110575 ] Andrew Grande commented on NIFI-6633: - Hi, this would be a great usability improvement. As a flow designer, I'd crafted a parameter context with a dozen values. Now, if I want to quickly test the flow against a different env (e.g. different data center in a remote geo), the natural motion is to clone a parameter context and update a few settings which need to change. Expected: some kind of parameter context browser and/or an action button to clone it (prompt for a new name). A user can then proceed and associate this new context with a PG as needed (same PG or a cloned one, for example). Actual: at the moment there's no experience like that, one can only create a new param context, meaning having to re-do all the work and enter every param again. Very error prone when done in the UI, too. > Allow user to copy a parameter context > -- > > Key: NIFI-6633 > URL: https://issues.apache.org/jira/browse/NIFI-6633 > Project: Apache NiFi > Issue Type: New Feature > Components: Core UI >Reporter: Rob Fellows >Priority: Major > > It would be nice to be able to copy/duplicate an existing parameter context. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7433) Update NiFi Toolkit docs to include new commands from 1.11.x
Andrew Grande created NIFI-7433: --- Summary: Update NiFi Toolkit docs to include new commands from 1.11.x Key: NIFI-7433 URL: https://issues.apache.org/jira/browse/NIFI-7433 Project: Apache NiFi Issue Type: Task Reporter: Andrew Grande https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#nifi_CLI Missing parameter context commands, maybe a few more new ones, needs a refresh. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFIREG-143) Sort ordering resets after a Flow delete operation
Andrew Grande created NIFIREG-143: - Summary: Sort ordering resets after a Flow delete operation Key: NIFIREG-143 URL: https://issues.apache.org/jira/browse/NIFIREG-143 Project: NiFi Registry Issue Type: Bug Affects Versions: 0.1.0 Reporter: Andrew Grande Display a list of flows in a bucket, order by Newest first. Make sure there are several flows listed, at least 3. Actions -> Delete. Expected: the ordering is preserved. Actual: the ordering resets and can potentially cause problems when a user tries to perform a semi-bulk operation like deleting multiple commonly named flows (e.g. the Quick Import - ones). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-141) Bucket descriptions in the Registry UI
[ https://issues.apache.org/jira/browse/NIFIREG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360056#comment-16360056 ] Andrew Grande commented on NIFIREG-141: --- Just ran into this (missing) issue. I am displaying the description in the CLI, querying the API. The data model suggests a description field, but UI doesn't ever expose it, so it's never set. > Bucket descriptions in the Registry UI > -- > > Key: NIFIREG-141 > URL: https://issues.apache.org/jira/browse/NIFIREG-141 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Kevin Doran >Priority: Minor > > On the backend, a bucket in NiFi Registry has an optional "description" field > that can be used to convey the intended purpose of a bucket, or a more > meaningful description than just what is used in the name. > This field should be settable (at bucket creation time and/or in the edit > bucket side panel) and rendered in the table and/or detail view of a bucket > in the NiFi Registry UI. > If NiFi is rendering this field, we should make sure that works correctly in > collaboration with this ticket. If NiFi is not displaying bucket descriptions > (for instance, when choosing where to initially save a flow), we should > consider if adding that information is useful in the NiFi UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NIFIREG-136) Switch to unique human-friendly names for buckets and flows
[ https://issues.apache.org/jira/browse/NIFIREG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351522#comment-16351522 ] Andrew Grande edited comment on NIFIREG-136 at 2/3/18 8:43 PM: --- Sure Kevin. If we keep using UUIDs *internally*, that would allow for any renaming support. The point really is shift the burden of dealing with uuids away from users, now that they are exposed to how NiFi handled PG, etc. The UUID has no meaning really when promoting to a different env (new bucket or different registry instance). I would like to think in terms of: # Copy this permalink of the flow version I want to promote. Or, if using a serialized flow version json file, I don't care about source UUIDs either. # 'Paste' it into the new bucket and/or registry instance (e.g. DEV -> QA). The target will be generating new uuids in any case (ideally transparently behind the scenes just by determining that path doesn't exist). Should it come to that, I can trade off Flow and Bucket names being immutable for having shareable and friendly URIs. was (Author: aperepel): Sure Kevin. If we keep using UUIDs *internally*, that would allow for any renaming support. The point really is shift the burden of dealing with uuids away from users, now that they are exposed to how NiFi handled PG, etc. The UUID has no meaning really when promoting to a different env (new bucket or different registry instance). I would like to think in terms of: # Copy this permalink of the flow version I want to promote. # 'Paste' it into the new bucket and/or registry instance (e.g. DEV -> QA). The target will be generating new uuids in any case (ideally transparently behind the scenes just by determining that path doesn't exist). Should it come to that, I can trade off Flow and Bucket names being immutable for having shareable and friendly URIs. > Switch to unique human-friendly names for buckets and flows > --- > > Key: NIFIREG-136 > URL: https://issues.apache.org/jira/browse/NIFIREG-136 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Andrew Grande >Priority: Major > > I have been playing with the Registry and using [~bende] 's early CLI to > accomplish some automation tasks. Have had really tough times with UUIDs > being used for buckets and flows, it introduced a lot of context switches to > locate/save/copy/paste those when using the API. > I would strongly suggest considering the human-friendly names and convert > deep links to using those instead. This not only provides for an easy > portable full URI, but also addresses compatibility issues between instances > of the registry, as buckets & flows with the same name are guaranteed to have > different UUIDs. A kind of copy/paste between environments. > I never came across a unique name requirement within a tree-like structure to > be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could > transparently reverse-look up the UUID by extracting names from the URI. The > goal is to have a great user experience. > P.S.: spaces in the name in the URI could be substituted for '+' sign > transparently, using the %20 would defeat the purpose of smooth ease-of-use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-136) Switch to unique human-friendly names for buckets and flows
[ https://issues.apache.org/jira/browse/NIFIREG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351522#comment-16351522 ] Andrew Grande commented on NIFIREG-136: --- Sure Kevin. If we keep using UUIDs *internally*, that would allow for any renaming support. The point really is shift the burden of dealing with uuids away from users, now that they are exposed to how NiFi handled PG, etc. The UUID has no meaning really when promoting to a different env (new bucket or different registry instance). I would like to think in terms of: # Copy this permalink of the flow version I want to promote. # 'Paste' it into the new bucket and/or registry instance (e.g. DEV -> QA). The target will be generating new uuids in any case (ideally transparently behind the scenes just by determining that path doesn't exist). Should it come to that, I can trade off Flow and Bucket names being immutable for having shareable and friendly URIs. > Switch to unique human-friendly names for buckets and flows > --- > > Key: NIFIREG-136 > URL: https://issues.apache.org/jira/browse/NIFIREG-136 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Andrew Grande >Priority: Major > > I have been playing with the Registry and using [~bende] 's early CLI to > accomplish some automation tasks. Have had really tough times with UUIDs > being used for buckets and flows, it introduced a lot of context switches to > locate/save/copy/paste those when using the API. > I would strongly suggest considering the human-friendly names and convert > deep links to using those instead. This not only provides for an easy > portable full URI, but also addresses compatibility issues between instances > of the registry, as buckets & flows with the same name are guaranteed to have > different UUIDs. A kind of copy/paste between environments. > I never came across a unique name requirement within a tree-like structure to > be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could > transparently reverse-look up the UUID by extracting names from the URI. The > goal is to have a great user experience. > P.S.: spaces in the name in the URI could be substituted for '+' sign > transparently, using the %20 would defeat the purpose of smooth ease-of-use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-138) UX: add an easy-to-copy permalink in the UI
Andrew Grande created NIFIREG-138: - Summary: UX: add an easy-to-copy permalink in the UI Key: NIFIREG-138 URL: https://issues.apache.org/jira/browse/NIFIREG-138 Project: NiFi Registry Issue Type: Improvement Reporter: Andrew Grande Think of github's `Clone or Download` button as a reference, it should be as easy and as few clicks as that one. Need a very simple and straightforward means to copy a deep link to the flow version I'm currently looking at in the UI, the main use case is to share this link further and automation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-137) Make 'Sort by: Newest' the default option
Andrew Grande created NIFIREG-137: - Summary: Make 'Sort by: Newest' the default option Key: NIFIREG-137 URL: https://issues.apache.org/jira/browse/NIFIREG-137 Project: NiFi Registry Issue Type: Improvement Reporter: Andrew Grande Not sure if sort order settings are saved per user, but at least initially we should promote the most recently updated flows to the top. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFIREG-136) Switch to unique human-friendly names for buckets and flows
[ https://issues.apache.org/jira/browse/NIFIREG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grande updated NIFIREG-136: -- Description: I have been playing with the Registry and using [~bende] 's early CLI to accomplish some automation tasks. Have had really tough times with UUIDs being used for buckets and flows, it introduced a lot of context switches to locate/save/copy/paste those when using the API. I would strongly suggest considering the human-friendly names and convert deep links to using those instead. This not only provides for an easy portable full URI, but also addresses compatibility issues between instances of the registry, as buckets & flows with the same name are guaranteed to have different UUIDs. A kind of copy/paste between environments. I never came across a unique name requirement within a tree-like structure to be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could transparently reverse-look up the UUID by extracting names from the URI. The goal is to have a great user experience. P.S.: spaces in the name in the URI could be substituted for '+' sign transparently, using the %20 would defeat the purpose of smooth ease-of-use. was: I have been playing with the Registry and using [~bende] 's early CLI to accomplish some automation tasks. Have had really tough times with UUIDs being used for buckets and flows, it introduced a lot of context switches to locate/save/copy/paste those when using the API. I would strongly suggest considering the human-friendly names and convert deep links to using those instead. This not only provides for an easy portable full URI, but also addresses compatibility issues between instances of the registry, as buckets & flows with the same name are guaranteed to have different UUIDs. A kind of copy/paste between environments. P.S.: spaces in the name in the URI could be substituted for '+' sign transparently, using the %20 would defeat the purpose of smooth ease-of-use. > Switch to unique human-friendly names for buckets and flows > --- > > Key: NIFIREG-136 > URL: https://issues.apache.org/jira/browse/NIFIREG-136 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Andrew Grande >Priority: Major > > I have been playing with the Registry and using [~bende] 's early CLI to > accomplish some automation tasks. Have had really tough times with UUIDs > being used for buckets and flows, it introduced a lot of context switches to > locate/save/copy/paste those when using the API. > I would strongly suggest considering the human-friendly names and convert > deep links to using those instead. This not only provides for an easy > portable full URI, but also addresses compatibility issues between instances > of the registry, as buckets & flows with the same name are guaranteed to have > different UUIDs. A kind of copy/paste between environments. > I never came across a unique name requirement within a tree-like structure to > be an issue when dealing with NiFi. E.g. NiFi and NiFi Registry could > transparently reverse-look up the UUID by extracting names from the URI. The > goal is to have a great user experience. > P.S.: spaces in the name in the URI could be substituted for '+' sign > transparently, using the %20 would defeat the purpose of smooth ease-of-use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-136) Switch to unique human-friendly names for buckets and flows
Andrew Grande created NIFIREG-136: - Summary: Switch to unique human-friendly names for buckets and flows Key: NIFIREG-136 URL: https://issues.apache.org/jira/browse/NIFIREG-136 Project: NiFi Registry Issue Type: Improvement Affects Versions: 0.1.0 Reporter: Andrew Grande I have been playing with the Registry and using [~bende] 's early CLI to accomplish some automation tasks. Have had really tough times with UUIDs being used for buckets and flows, it introduced a lot of context switches to locate/save/copy/paste those when using the API. I would strongly suggest considering the human-friendly names and convert deep links to using those instead. This not only provides for an easy portable full URI, but also addresses compatibility issues between instances of the registry, as buckets & flows with the same name are guaranteed to have different UUIDs. A kind of copy/paste between environments. P.S.: spaces in the name in the URI could be substituted for '+' sign transparently, using the %20 would defeat the purpose of smooth ease-of-use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-89) Add a default URL handler for root '/' instead of returning a 404
[ https://issues.apache.org/jira/browse/NIFIREG-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351509#comment-16351509 ] Andrew Grande commented on NIFIREG-89: -- As much as I love NiFi's 'you may have meant /nifi', I'm vouching for just redirecting the user to the correct context path. It's hard enough to memorize dozens of various ports, no need to add the context path to the pile. Thanks! > Add a default URL handler for root '/' instead of returning a 404 > - > > Key: NIFIREG-89 > URL: https://issues.apache.org/jira/browse/NIFIREG-89 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Danny Lane >Assignee: Danny Lane >Priority: Minor > Labels: usability > > Currently when you land on the root or a NiFi Registry deployment you get a > 404 response from Jetty. > It was suggested in the mailing list to add a page similar to the NiFi 'You > may have mistyped...' page. > This is item to track that suggestion and associated work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4005) Add support for Azure Shared Access Signature (SAS) Tokens
[ https://issues.apache.org/jira/browse/NIFI-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292853#comment-16292853 ] Andrew Grande commented on NIFI-4005: - Hi Koji, you can proceed with all suggested changes and take it over, thank you. > Add support for Azure Shared Access Signature (SAS) Tokens > -- > > Key: NIFI-4005 > URL: https://issues.apache.org/jira/browse/NIFI-4005 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.2.0 >Reporter: Andrew Grande >Priority: Minor > > Azure's account name and key are treated as admin, 'root' access credentials. > If one has those, every container under this account is fully accessible. An > MSFT-recommended approach is to use SAS policies, which provide for a fine > grained permission and object control, as well as defined expiration. > I already have working code, filing this ticket to formally track and submit > PR against next. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4012) Azure Event Hub UI typos and cleanup
Andrew Grande created NIFI-4012: --- Summary: Azure Event Hub UI typos and cleanup Key: NIFI-4012 URL: https://issues.apache.org/jira/browse/NIFI-4012 Project: Apache NiFi Issue Type: Improvement Reporter: Andrew Grande Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NIFI-4005) Add support for Azure Shared Access Signature (SAS) Tokens
Andrew Grande created NIFI-4005: --- Summary: Add support for Azure Shared Access Signature (SAS) Tokens Key: NIFI-4005 URL: https://issues.apache.org/jira/browse/NIFI-4005 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.2.0 Reporter: Andrew Grande Priority: Minor Azure's account name and key are treated as admin, 'root' access credentials. If one has those, every container under this account is fully accessible. An MSFT-recommended approach is to use SAS policies, which provide for a fine grained permission and object control, as well as defined expiration. I already have working code, filing this ticket to formally track and submit PR against next. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NIFI-3982) Scripting - include additional util, helper and extension classes in the namespace
Andrew Grande created NIFI-3982: --- Summary: Scripting - include additional util, helper and extension classes in the namespace Key: NIFI-3982 URL: https://issues.apache.org/jira/browse/NIFI-3982 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 1.2.0 Reporter: Andrew Grande Priority: Minor When messing with InvokeScriptedProcessor one doesn't have to import NiFi framework classes (they are injected into the script's namespace). However, there are lots of utility modules which aren't imported. E.g. I had to explicitly add the import statement in my script for the following: *import org.apache.nifi.flowfile.attributes.CoreAttributes* This class is in nifi-commons -> nifi-utils -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NIFI-2828) SelectHiveQL and PutHiveQL fail with NoClassDefFoundError when using HTTP transport
[ https://issues.apache.org/jira/browse/NIFI-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15526688#comment-15526688 ] Andrew Grande commented on NIFI-2828: - I saw the same stacktrace for the PutHiveQL processor when connecting to Hive over HTTP. > SelectHiveQL and PutHiveQL fail with NoClassDefFoundError when using HTTP > transport > > > Key: NIFI-2828 > URL: https://issues.apache.org/jira/browse/NIFI-2828 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joey Frazee >Assignee: Matt Burgess > Fix For: 1.1.0 > > > SelectHiveQL and PutHiveQL don't currently work with HTTP transport. There > appears to be a class loader problem resulting in > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.http.conn.ssl.SSLConnectionSocketFactory. > This looks like a conflict with the Apache commons httpclient version in > hadoop-common. Removing the hadoop-libraries .nar dependency and provided > scope for hadoop-common appears to fix the issue, but I haven't done any > rigorous testing so I'm not sure if there are other consequences or not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2822) JoltTransformer Advanced UI doesn't load in a secured cluster
Andrew Grande created NIFI-2822:
---
Summary: JoltTransformer Advanced UI doesn't load in a secured
cluster
Key: NIFI-2822
URL: https://issues.apache.org/jira/browse/NIFI-2822
Project: Apache NiFi
Issue Type: Bug
Components: Core UI
Affects Versions: 1.0.0
Environment: LDAP-secured 3 node NiFi cluster
Reporter: Andrew Grande
JoltTransformer -> click Advanced. The UI doesn't load - "An error has occurred
loading the editor."
The error on the backend is below, doesn't seem to pass authorization tokens at
all, lists 'anonymous':
{noformat}
2016-09-26 09:19:16,794 WARN NiFi Web Server-74433 -
org.eclipse.jetty.servlet.ServletHandler
/nifi-jolt-transform-json-ui-1.0.0.2.0.0.0-579/api/standard/processor/details
org.apache.nifi.authorization.AccessDeniedException: Unknown user with identity
'anonymous'.
at
org.apache.nifi.authorization.resource.Authorizable.authorize(Authorizable.java:166)
~[nifi-framework-api-1.0.0.2.0.0.0-579.jar:1.0.0.2.0.0.0-579]
at
org.apache.nifi.authorization.resource.Authorizable.authorize(Authorizable.java:163)
~[nifi-framework-api-1.0.0.2.0.0.0-579.jar:1.0.0.2.0.0.0-579]
at
org.apache.nifi.authorization.resource.Authorizable.authorize(Authorizable.java:179)
~[nifi-framework-api-1.0.0.2.0.0.0-579.jar:1.0.0.2.0.0.0-579]
at
org.apache.nifi.web.StandardNiFiWebConfigurationContext$ProcessorFacade.lambda$getComponentDetails$0(StandardNiFiWebConfigurationContext.java:342)
~[na:na]
at
org.apache.nifi.web.StandardNiFiServiceFacade.authorizeAccess(StandardNiFiServiceFacade.java:289)
~[na:na]
at
org.apache.nifi.web.StandardNiFiServiceFacade$$FastClassBySpringCGLIB$$358780e0.invoke()
~[na:na]
at
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
~[na:na]
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
~[na:na]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
~[na:na]
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
~[na:na]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
~[na:na]
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
~[na:na]
at
org.apache.nifi.web.StandardNiFiServiceFacade$$EnhancerBySpringCGLIB$$80c8c166.authorizeAccess()
~[na:na]
at
org.apache.nifi.web.StandardNiFiWebConfigurationContext$ProcessorFacade.getComponentDetails(StandardNiFiWebConfigurationContext.java:340)
~[na:na]
at
org.apache.nifi.web.StandardNiFiWebConfigurationContext.getComponentDetails(StandardNiFiWebConfigurationContext.java:256)
~[na:na]
at
org.apache.nifi.web.standard.api.processor.ProcessorWebUtils.getComponentDetails(ProcessorWebUtils.java:47)
~[classes/:na]
at
org.apache.nifi.web.standard.api.processor.ProcessorWebUtils.getComponentDetails(ProcessorWebUtils.java:52)
~[classes/:na]
at
org.apache.nifi.web.standard.api.processor.ProcessorResource.getDetails(ProcessorResource.java:49)
~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_77]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_77]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_77]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_77]
at
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
~[jersey-server-1.19.1.jar:1.19.1]
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
[jira] [Updated] (NIFI-2788) Cluster icon in the menu doesn't have a consistent size
[ https://issues.apache.org/jira/browse/NIFI-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grande updated NIFI-2788: Attachment: (was: screenshot-1.png) > Cluster icon in the menu doesn't have a consistent size > --- > > Key: NIFI-2788 > URL: https://issues.apache.org/jira/browse/NIFI-2788 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 > Environment: OSX, Chrome >Reporter: Andrew Grande >Priority: Trivial > Attachments: screenshot.png > > > The global menu cluster icon has incorrect size, the Cluster menu item is > shifted to the right as a result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2788) Cluster icon in the menu doesn't have a consistent size
[ https://issues.apache.org/jira/browse/NIFI-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grande updated NIFI-2788: Attachment: screenshot-1.png > Cluster icon in the menu doesn't have a consistent size > --- > > Key: NIFI-2788 > URL: https://issues.apache.org/jira/browse/NIFI-2788 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 > Environment: OSX, Chrome >Reporter: Andrew Grande >Priority: Trivial > Attachments: screenshot.png > > > The global menu cluster icon has incorrect size, the Cluster menu item is > shifted to the right as a result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2788) Cluster icon in the menu doesn't have a consistent size
Andrew Grande created NIFI-2788: --- Summary: Cluster icon in the menu doesn't have a consistent size Key: NIFI-2788 URL: https://issues.apache.org/jira/browse/NIFI-2788 Project: Apache NiFi Issue Type: Bug Components: Core UI Affects Versions: 1.0.0 Environment: OSX, Chrome Reporter: Andrew Grande Priority: Trivial Attachments: screenshot.png The global menu cluster icon has incorrect size, the Cluster menu item is shifted to the right as a result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2788) Cluster icon in the menu doesn't have a consistent size
[ https://issues.apache.org/jira/browse/NIFI-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grande updated NIFI-2788: Attachment: screenshot.png > Cluster icon in the menu doesn't have a consistent size > --- > > Key: NIFI-2788 > URL: https://issues.apache.org/jira/browse/NIFI-2788 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 1.0.0 > Environment: OSX, Chrome >Reporter: Andrew Grande >Priority: Trivial > Attachments: screenshot.png > > > The global menu cluster icon has incorrect size, the Cluster menu item is > shifted to the right as a result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2786) TLS Toolkit doesn't support -outputDirectory property in all modes
Andrew Grande created NIFI-2786: --- Summary: TLS Toolkit doesn't support -outputDirectory property in all modes Key: NIFI-2786 URL: https://issues.apache.org/jira/browse/NIFI-2786 Project: Apache NiFi Issue Type: Bug Components: Tools and Build Affects Versions: 1.0.0 Reporter: Andrew Grande Priority: Minor TLS toolkit has 3 modes: # standalone # server (host a CA authority server) # client (remotely interact with CA authority server) There is an -o option to dump all artifacts (config, keystore, truststore) in a dedicated directory (default is . ). However, it's not a supported property for server and client mode. This is most useful for 'client' mode. When running on a remote workstation to create new certs signed by a NiFi CA authority, quite a few files are saved. If I need to generate multiple certs for multiple people I would have to manually move files out of the way (otherwise they are overwritten). Expected: add -o/--outputDirectory to the client mode (maybe server too). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2365) More prominent pointer to docs for a given type of user
[ https://issues.apache.org/jira/browse/NIFI-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grande updated NIFI-2365: Description: An example is the *Developer Guide*, as well as the *NiFi in Depth*. These are buried in the docs at the very bottom. Consider bringing dedicated doc sections in the main site menu for these personas: * User/DFM * Developer (custom processors) * Admin * Contributor was: An example is the *Developer Guide*, as well as the *NiFi in Depth*. These are buried in the docs at the very bottom. Consider bringing dedicated doc sections for these personas: * User/DFM * Developer (custom processors) * Admin * Contributor > More prominent pointer to docs for a given type of user > --- > > Key: NIFI-2365 > URL: https://issues.apache.org/jira/browse/NIFI-2365 > Project: Apache NiFi > Issue Type: Task > Components: Documentation & Website >Reporter: Andrew Grande > > An example is the *Developer Guide*, as well as the *NiFi in Depth*. These > are buried in the docs at the very bottom. > Consider bringing dedicated doc sections in the main site menu for these > personas: > * User/DFM > * Developer (custom processors) > * Admin > * Contributor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2365) More prominent pointer to docs for a given type of user
Andrew Grande created NIFI-2365: --- Summary: More prominent pointer to docs for a given type of user Key: NIFI-2365 URL: https://issues.apache.org/jira/browse/NIFI-2365 Project: Apache NiFi Issue Type: Task Components: Documentation & Website Reporter: Andrew Grande An example is the *Developer Guide*, as well as the *NiFi in Depth*. These are buried in the docs at the very bottom. Consider bringing dedicated doc sections for these personas: * User/DFM * Developer (custom processors) * Admin * Contributor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
