Re: [DISCUSS] Feature proposal: Read-only mode as default
Here's my .02: Regarding read-only, if that is all that's implemented, the user still faces the challenge of unintended changes once they engage edit mode. Already mentioned but of personal preference, the 'undo' action. Pair undo with a notification of the change that was made, think like Gmail or Inbox. To expand on this further, introduce a history feature with the ability to revert back to past states (in case something goes unnoticed). I also see usefulness in confirmation dialogs in combination with notification/undo functionality, reserved for extreme cases where significant change would occur. Another idea to consider is explicit tools. By default the cursor could be a move or grab icon that only lets the user navigate the graph. They could click anywhere, on anything to navigate. Then, an explicit action to choose a 'selection' tool that will enable them to click on and select an item for follow-on action. Keyboard shortcuts could be introduced allowing advanced users to quickly shift between tools. On Mon, Aug 10, 2015 at 6:00 PM johny casanova wrote: > I agree I think Mark explained it right on the money what I was trying to > say before. > On Aug 10, 2015 3:44 PM, "Mark Payne" wrote: > > > I'm definitely a +1. I accidentally drag processors all the time when I'm > > panning around a large graph. > > > > I can understand how someone would get annoyed with this, though, and I > > can also appreciate the desire > > to not start storing user preferences. However, I think we should > probably > > at least supply a system-level > > configuration for whether or not to have "read-only" the default mode. > > Then administrators can turn it on > > or off, depending on the users of the system. > > > > > > > > > > > Date: Sat, 8 Aug 2015 20:50:07 -0400 > > > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > > > From: a...@adamtaft.com > > > To: dev@nifi.apache.org > > > > > > Thinking about it some more, I don't mind the concept of "read only" > > > toggle. Maybe it's not set by default, but it could be a really easy UI > > > element to add somewhere. Just a little slider-toggle element. [1] > > > > > > In theory, this might be a UI only feature, it wouldn't strictly need > > > support in the backend api (just guessing). The logic is seemingly > > already > > > there, similar user experience as non-DFMs. > > > > > > Anyway, +1 to the concept of read-only toggle mode. -1 for making it > > > default, but the user interface element should be easy to work either > > way. > > > > > > Also agree that undo support might be free if versioning is added. > > > > > > [1] > > http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg > > > > > > > > > > > > > > > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: > > > > > >> Ryan - the other useful case for read-only is basically when is > > >> scanning around the graph and accidentally moves a processor or > > >> relationship. By no means a big deal. The idea here was to make it > > >> explicit though that the user wishes to go into an edit mode. > > >> > > >> I do think the undo mechanism plays well and you're right that we can > > >> just focus on tightening up the delete case. > > >> > > >> Sounds like the prevailing view is to avoid read-only as a mode but > > >> rather to make it more explicit whenever we delete - and potentially > > >> move we could make more specific rather than simply them having > > >> clicked and dragged which is ambiguous with the process of panning. > > >> > > >> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: > > >>> I'm not a big fan of having a read-only mode by default. It sounds > like > > >>> something that would be frustrating for users when they try to make > > >> changes > > >>> and then have to figure out how to switch modes. > > >>> > > >>> I think a clearer picture of the problem we're trying to solve would > > >> help my > > >>> understanding. I'm primarily thinking of the delete case you > mentioned > > >> with > > >>> these comments... > > >>> > > >>> If we're talking about accidentally deleting processors, then the > > current > > >>> mechanisms (IIRC) work pretty well: not deleting a running processor, > > one > > >>> that has live incoming connections, etc. If those rules are > > >> insufficient, I > > >>> would explore extending them rather than having a global read-only > > mode. > > >>> > > >>> For the case where the wrong processor is selected because it is off > > the > > >>> screen, maybe having the confirmation pop up if anything affected > > wasn't > > >>> displayed to confirm? That way we don't have confirmations all the > time > > >> but > > >>> still don't do unexpected things. > > >>> > > >>> I really like the idea of "undo" as well. If that is limited to > > >> processors > > >>> that weren't running (because you can't delete ones that are), then > > that > > >>> makes the undo operation easier to implement. > > >>> > > >>> rb
RE: [DISCUSS] Feature proposal: Read-only mode as default
I agree I think Mark explained it right on the money what I was trying to say before. On Aug 10, 2015 3:44 PM, "Mark Payne" wrote: > I'm definitely a +1. I accidentally drag processors all the time when I'm > panning around a large graph. > > I can understand how someone would get annoyed with this, though, and I > can also appreciate the desire > to not start storing user preferences. However, I think we should probably > at least supply a system-level > configuration for whether or not to have "read-only" the default mode. > Then administrators can turn it on > or off, depending on the users of the system. > > > > > > Date: Sat, 8 Aug 2015 20:50:07 -0400 > > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > > From: a...@adamtaft.com > > To: dev@nifi.apache.org > > > > Thinking about it some more, I don't mind the concept of "read only" > > toggle. Maybe it's not set by default, but it could be a really easy UI > > element to add somewhere. Just a little slider-toggle element. [1] > > > > In theory, this might be a UI only feature, it wouldn't strictly need > > support in the backend api (just guessing). The logic is seemingly > already > > there, similar user experience as non-DFMs. > > > > Anyway, +1 to the concept of read-only toggle mode. -1 for making it > > default, but the user interface element should be easy to work either > way. > > > > Also agree that undo support might be free if versioning is added. > > > > [1] > http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg > > > > > > > > > > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: > > > >> Ryan - the other useful case for read-only is basically when is > >> scanning around the graph and accidentally moves a processor or > >> relationship. By no means a big deal. The idea here was to make it > >> explicit though that the user wishes to go into an edit mode. > >> > >> I do think the undo mechanism plays well and you're right that we can > >> just focus on tightening up the delete case. > >> > >> Sounds like the prevailing view is to avoid read-only as a mode but > >> rather to make it more explicit whenever we delete - and potentially > >> move we could make more specific rather than simply them having > >> clicked and dragged which is ambiguous with the process of panning. > >> > >> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: > >>> I'm not a big fan of having a read-only mode by default. It sounds like > >>> something that would be frustrating for users when they try to make > >> changes > >>> and then have to figure out how to switch modes. > >>> > >>> I think a clearer picture of the problem we're trying to solve would > >> help my > >>> understanding. I'm primarily thinking of the delete case you mentioned > >> with > >>> these comments... > >>> > >>> If we're talking about accidentally deleting processors, then the > current > >>> mechanisms (IIRC) work pretty well: not deleting a running processor, > one > >>> that has live incoming connections, etc. If those rules are > >> insufficient, I > >>> would explore extending them rather than having a global read-only > mode. > >>> > >>> For the case where the wrong processor is selected because it is off > the > >>> screen, maybe having the confirmation pop up if anything affected > wasn't > >>> displayed to confirm? That way we don't have confirmations all the time > >> but > >>> still don't do unexpected things. > >>> > >>> I really like the idea of "undo" as well. If that is limited to > >> processors > >>> that weren't running (because you can't delete ones that are), then > that > >>> makes the undo operation easier to implement. > >>> > >>> rb > >>> > >>> > >>> On 08/08/2015 11:31 AM, Joe Witt wrote: > > I can dig the user pref aspect but it would mean we start storing user > prefs which is a bummer. > On Aug 8, 2015 1:42 PM, "Tony Kurc" wrote: > > > Personally not a fan of the idea. Maybe something analogous to > >> something > > like 'lock the taskbar' in Windows that can have a system default > >> setting > > and a user preference of on or off. > > > > On Sat, Aug 8, 2015 at 11:44 AM, johny casanova < > > computertech2...@gmail.com> > > wrote: > > > >> I agree it is easy to move it delete something by mistake. Some > flows > >> are > >> huge or are using,more resources and are slower to load and you can > >> accidently do something by mistake. I believe the "are yous sure u > >> want > > > > to > >> > >> delete?" its a good start. > >> On Aug 7, 2015 10:31 PM, "Joe Witt" wrote: > >> > >>> Team, > >>> > >>> We've been hearing from users of nifi that it is too easy to > >>> accidentally move something on the flow or delete large portions of > >>> the flow. This is the case when panning the screen for example and > >>> accidentally having a processor selected instead. > >>> > >
RE: [DISCUSS] Feature proposal: Read-only mode as default
Accidentally moving processors is the main reason that I like this idea. However, I would like to see it truly in read-only mode. If I go to Configure a processor, I may still not want to edit the processor. I may just want to view the configuration and I'd like to ensure that I don't accidentally change (or delete) something. > Date: Mon, 10 Aug 2015 13:02:35 -0700 > From: b...@cloudera.com > To: dev@nifi.apache.org > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > > If we're talking about read-only mode as a way to avoid moving > processors when moving around on the graph, what about implementing > something slightly different? What about having a toggle between > drag-to-scroll and drag-to-move? Then users could keep the toggle in > drag-to-scroll most of the time (and undo would put things back when the > inevitable accident happens). > > Then deletes would be handled by more sophisticated rules, like not > deleting processors that are off the screen without confirmation. > > rb > > On 08/10/2015 12:58 PM, Dan Bress wrote: >> +1 to exactly what Mark described in his last email for a system wide >> preference. >> >> Although I'm curious how you leave read-only mode and get into edit mode? >> And how do you leave edit mode and go back to read-only mode? >> >> On one hand, if I do not intend to edit the graph and I accidentally move a >> processor I probably don't want it to prompt me "do you want to enter edit >> mode?" >> -In read-only mode, I think it would be a nice user experience to click >> anywhere on the graph(including on a processor) and it moves the entire >> graph. >> On the other hand, if I right click a processor and hit configure I'd like >> to leave read-only mode and go into edit mode. I'm not sure I'd even want to >> be prompted with "do you want to enter edit mode?" here since I obviously do. >> >> >> Dan Bress >> Software Engineer >> ONYX Consulting Services >> >> >> From: Mark Payne >> Sent: Monday, August 10, 2015 3:43 PM >> To: dev@nifi.apache.org >> Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default >> >> I'm definitely a +1. I accidentally drag processors all the time when I'm >> panning around a large graph. >> >> I can understand how someone would get annoyed with this, though, and I can >> also appreciate the desire >> to not start storing user preferences. However, I think we should probably >> at least supply a system-level >> configuration for whether or not to have "read-only" the default mode. Then >> administrators can turn it on >> or off, depending on the users of the system. >> >> >> >> >>> Date: Sat, 8 Aug 2015 20:50:07 -0400 >>> Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default >>> From: a...@adamtaft.com >>> To: dev@nifi.apache.org >>> >>> Thinking about it some more, I don't mind the concept of "read only" >>> toggle. Maybe it's not set by default, but it could be a really easy UI >>> element to add somewhere. Just a little slider-toggle element. [1] >>> >>> In theory, this might be a UI only feature, it wouldn't strictly need >>> support in the backend api (just guessing). The logic is seemingly already >>> there, similar user experience as non-DFMs. >>> >>> Anyway, +1 to the concept of read-only toggle mode. -1 for making it >>> default, but the user interface element should be easy to work either way. >>> >>> Also agree that undo support might be free if versioning is added. >>> >>> [1] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg >>> >>> >>> >>> >>> On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: >>> Ryan - the other useful case for read-only is basically when is scanning around the graph and accidentally moves a processor or relationship. By no means a big deal. The idea here was to make it explicit though that the user wishes to go into an edit mode. I do think the undo mechanism plays well and you're right that we can just focus on tightening up the delete case. Sounds like the prevailing view is to avoid read-only as a mode but rather to make it more explicit whenever we delete - and potentially move we could make more specific rather than simply them having clicked and dragged which is ambiguous with the process of panning. On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: > I'm not a big fan of having a read-only mode by default. It sounds like > something that would be frustrating for users when they try to make changes > and then have to figure out how to switch modes. > > I think a clearer picture of the problem we're trying to solve would help my > understanding. I'm primarily thinking of the delete case you mentioned with > these comments... > > If we're talking about accidentally deleting processors, then the cu
Re: eliminate nifi-parent, split out nifi-nar-maven-plugin, have nifi in its own tree
Ryan Correct the latest code depends on latest nifi nar maven plugin. I would be absolutely fine personally with eliminating develop and just using master. Given that the releases are tagged i personally dont get the value here vs the extra work required. Anybody feel strongly for keeping master and dev as they are and if so can you please state how the current model has helped you contribute or how the proposed model would not? Thanks Joe On Aug 10, 2015 11:43 AM, "Ryan Blue" wrote: > +1 > > I think separate git repos is a great idea. One thing to clarify, too: > most of the time the nifi project relies on the last nifi-nar-maven-plugin > release, right? So that should be transparent for most people building the > project. It would only be awkward for someone updating the maven plugin and > testing it out locally because the develop branch should always track a > release. > > Speaking of the develop branch... what about using master like most > projects after this change? > > rb > > On 08/10/2015 07:32 AM, Joe Witt wrote: > >> Team, >> >> We've seen and heard the confusion of folks trying to build NiFi's >> goofy three step build process with parent, nar plugin, and nifi. I >> propose to do the following: >> >> 1) Eliminate the nifi-parent by pushing anything necessary back into >> nifi-nar-maven-plugin. The DRY concept is valid but just not worth a >> third project at this point given how little it avoids meaningful >> repetition on. >> >> 2) Create a new apache git repo for 'nifi-maven-plugins' and move the >> 'nifi-nar-maven-plugin' content into it. >> >> 3) Remove the nifi-parent and nifi-nar-maven-plugin from nifi folder >> and promote the current 'nifi' sub folder to the top level. >> >> Why: Folks are confused as to why they need to build all three and it >> is odd that in a given project folder you would have to each manually. >> It is just not a generally appreciated fact that you cannot have a >> dependency on a maven plugin within the same reactor build that uses >> that builds that plugin. By cleaning this up people can just download >> the source and build it. We don't have to have any protracted build >> cycles for 'nifi maven plugings' anymore leaving dependency on a >> snapshot in the nifi tree. >> >> If there seems to be consensus on this i'll put in the infra ticket soon. >> >> Thanks >> Joe >> >> > > -- > Ryan Blue > Software Engineer > Cloudera, Inc. >
Re: Help required with my custom controller service
All That certainly cured the problem in my case. Dave Sent from Yahoo! Mail on Android
Re: Help required with my custom controller service
Bryan and Mark,
I suspect that will do it. I'll check tomorrow.
Brandon
On Mon, Aug 10, 2015, 4:23 PM Bryan Bende wrote:
> Not sure if this is helpful, but there is a section about adding
> dependencies on controller services at the end of this wiki page:
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Custom+Processors
>
>
> On Monday, August 10, 2015, Mark Payne wrote:
>
> > Brandon,
> >
> > I've seen this occur when I forgot to add a dependency on the
> > ssl-context-service-api-nar in my NAR's pom.
> >
> > You should have something like:
> >
> > org.apache.nifi
> > ssl-context-service-api
> > 0.3.0-SNAPSHOT
> > nar
> >
> >
> > Is that by chance the issue, or is there something else going on?
> >
> > Thanks
> > -Mark
> >
> >
> > > From: b...@jhu.edu
> > > Date: Mon, 10 Aug 2015 19:13:50 +
> > > Subject: Re: Help required with my custom controller service
> > > To: dev@nifi.apache.org
> > >
> > > All,
> > >
> > > Was this ever solved / explained? I'm having a similar issue. If
> there's
> > > a simple answer that I'm missing that would be great... otherwise I
> might
> > > post an example set of NARs somewhere tomorrow. Probably the simplest
> > > question first is, if I want to create a custom processor that uses a
> > > SSLContextService, what dependencies do I need to add where (assuming
> > we're
> > > using the processor NAR archetype)? I've created an example that
> > compiles,
> > > loads in NiFi, and can be dropped on the graph. However, it can not be
> > > configured to use any currently existing SSLContextService, and any
> that
> > > are created have the same UUID issue described by David. Thoughts?
> > >
> > > Brandon
> > >
> > >
> > >
> > > On Tue, Jul 28, 2015 at 10:50 AM Mark Payne > > wrote:
> > >
> > >> Dave,
> > >>
> > >> In addition to the points that Aldrin brought up, are your
> CacheService
> > >> interface
> > >> and StandardCacheService classes in the same NAR?
> > >>
> > >> If they are not in the same NAR, does your NAR for
> StandardCacheService
> > >> have a Maven dependency
> > >> on the NAR that houses CacheService?
> > >>
> > >> Thanks
> > >> -Mark
> > >>
> > >>
> > >>> From: aldrinp...@gmail.com
> > >>> Date: Mon, 27 Jul 2015 23:26:58 -0400
> > >>> Subject: Re: Help required with my custom controller service
> > >>> To: dev@nifi.apache.org ; davidrsm...@btinternet.com
> >
> > >>>
> > >>> Dave,
> > >>>
> > >>> Some quick notes as I work through your setup.
> > >>>
> > >>> Did you create an entry in your
> > >>> NAR's org.apache.nifi.controller.ControllerService file? This would
> be
> > in
> > >>> src/main/resources/META-INF/services directory of your project. It
> > seems
> > >>> like this isn't likely the case, but a point that can sometimes get
> > >>> overlooked.
> > >>>
> > >>> Your accessing of the service property in your processor looks good.
> > >>>
> > >>> Did you accidentally override
> > AbstractControllerService#getIdentifier()?
> > >>> It seems like this could lead to the error you are seeing, but it is
> > hard
> > >>> to be sure.
> > >>>
> > >>> If you are able to share more code with us, we can provide some more
> > >>> pointed assistance. Have you managed to get your processor and
> > controller
> > >>> service running within the test framework [1]? If not, I would
> suggest
> > >>> doing so to cut down on iterations in debugging your problems as well
> > as
> > >>> providing a means for you to easily step through the code.
> > >>>
> > >>> [1]
> > >>
> http://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#testing
> > >>>
> > >>> On Sun, Jul 26, 2015 at 4:45 PM, DAVID SMITH <
> > davidrsm...@btinternet.com
> > >>>
> > >>> wrote:
> > >>>
> > Hi
> > I have been trying to write a simple Cache Controller Service that
> > uses
> > >> a
> > Map to hold key/value pairs. I am using
> > nifi-0.1.0-incubating. I have created an Interface called
> CacheService
> > which extends ControllerService.public interface CacheService
> extends
> > ControllerService {
> >
> > I have created an implementation called StandardCacheService which
> is
> > as
> > follows:
> > public class StandardCacheService extends AbstractControllerService
> > implements CacheService {
> > I have compiled the StandardCacheService and created a nar which I
> > have
> > then put into my NiFi lib directory, my StandardCacheService
> > Controller
> > Service appears in the Controller services tab of the NiFi Flow
> > Settings
> > panel, I can edit it and enable it. Also there are no abnormal log
> > >> messages.
> > However, when I try to configure the CacheService in my test
> > Processor,
> > again I get no errors but when I cannot see my StandardCacheService.
> > My
> > processor has the following snippets to implement the Cache
> > Service/Controller:
> > p
Re: Help required with my custom controller service
Not sure if this is helpful, but there is a section about adding
dependencies on controller services at the end of this wiki page:
https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Custom+Processors
On Monday, August 10, 2015, Mark Payne wrote:
> Brandon,
>
> I've seen this occur when I forgot to add a dependency on the
> ssl-context-service-api-nar in my NAR's pom.
>
> You should have something like:
>
> org.apache.nifi
> ssl-context-service-api
> 0.3.0-SNAPSHOT
> nar
>
>
> Is that by chance the issue, or is there something else going on?
>
> Thanks
> -Mark
>
>
> > From: b...@jhu.edu
> > Date: Mon, 10 Aug 2015 19:13:50 +
> > Subject: Re: Help required with my custom controller service
> > To: dev@nifi.apache.org
> >
> > All,
> >
> > Was this ever solved / explained? I'm having a similar issue. If there's
> > a simple answer that I'm missing that would be great... otherwise I might
> > post an example set of NARs somewhere tomorrow. Probably the simplest
> > question first is, if I want to create a custom processor that uses a
> > SSLContextService, what dependencies do I need to add where (assuming
> we're
> > using the processor NAR archetype)? I've created an example that
> compiles,
> > loads in NiFi, and can be dropped on the graph. However, it can not be
> > configured to use any currently existing SSLContextService, and any that
> > are created have the same UUID issue described by David. Thoughts?
> >
> > Brandon
> >
> >
> >
> > On Tue, Jul 28, 2015 at 10:50 AM Mark Payne > wrote:
> >
> >> Dave,
> >>
> >> In addition to the points that Aldrin brought up, are your CacheService
> >> interface
> >> and StandardCacheService classes in the same NAR?
> >>
> >> If they are not in the same NAR, does your NAR for StandardCacheService
> >> have a Maven dependency
> >> on the NAR that houses CacheService?
> >>
> >> Thanks
> >> -Mark
> >>
> >>
> >>> From: aldrinp...@gmail.com
> >>> Date: Mon, 27 Jul 2015 23:26:58 -0400
> >>> Subject: Re: Help required with my custom controller service
> >>> To: dev@nifi.apache.org ; davidrsm...@btinternet.com
>
> >>>
> >>> Dave,
> >>>
> >>> Some quick notes as I work through your setup.
> >>>
> >>> Did you create an entry in your
> >>> NAR's org.apache.nifi.controller.ControllerService file? This would be
> in
> >>> src/main/resources/META-INF/services directory of your project. It
> seems
> >>> like this isn't likely the case, but a point that can sometimes get
> >>> overlooked.
> >>>
> >>> Your accessing of the service property in your processor looks good.
> >>>
> >>> Did you accidentally override
> AbstractControllerService#getIdentifier()?
> >>> It seems like this could lead to the error you are seeing, but it is
> hard
> >>> to be sure.
> >>>
> >>> If you are able to share more code with us, we can provide some more
> >>> pointed assistance. Have you managed to get your processor and
> controller
> >>> service running within the test framework [1]? If not, I would suggest
> >>> doing so to cut down on iterations in debugging your problems as well
> as
> >>> providing a means for you to easily step through the code.
> >>>
> >>> [1]
> >> http://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#testing
> >>>
> >>> On Sun, Jul 26, 2015 at 4:45 PM, DAVID SMITH <
> davidrsm...@btinternet.com
> >>>
> >>> wrote:
> >>>
> Hi
> I have been trying to write a simple Cache Controller Service that
> uses
> >> a
> Map to hold key/value pairs. I am using
> nifi-0.1.0-incubating. I have created an Interface called CacheService
> which extends ControllerService.public interface CacheService extends
> ControllerService {
>
> I have created an implementation called StandardCacheService which is
> as
> follows:
> public class StandardCacheService extends AbstractControllerService
> implements CacheService {
> I have compiled the StandardCacheService and created a nar which I
> have
> then put into my NiFi lib directory, my StandardCacheService
> Controller
> Service appears in the Controller services tab of the NiFi Flow
> Settings
> panel, I can edit it and enable it. Also there are no abnormal log
> >> messages.
> However, when I try to configure the CacheService in my test
> Processor,
> again I get no errors but when I cannot see my StandardCacheService.
> My
> processor has the following snippets to implement the Cache
> Service/Controller:
> public static final PropertyDescriptor CACHE_SERVICE = new
> PropertyDescriptor.Builder()
> .name("Cache Service")
> .description("The Controller Service to use in order to obtain a
> Cache Service")
> .required(false)
> .identifiesControllerService(CacheService.class)
> .build();
>
> final CacheService cache =
>
> >>
> context.getProperty(CACHE_SERVICE).asControllerServi
Re: [DISCUSS] Feature proposal: Read-only mode as default
If we're talking about read-only mode as a way to avoid moving processors when moving around on the graph, what about implementing something slightly different? What about having a toggle between drag-to-scroll and drag-to-move? Then users could keep the toggle in drag-to-scroll most of the time (and undo would put things back when the inevitable accident happens). Then deletes would be handled by more sophisticated rules, like not deleting processors that are off the screen without confirmation. rb On 08/10/2015 12:58 PM, Dan Bress wrote: +1 to exactly what Mark described in his last email for a system wide preference. Although I'm curious how you leave read-only mode and get into edit mode? And how do you leave edit mode and go back to read-only mode? On one hand, if I do not intend to edit the graph and I accidentally move a processor I probably don't want it to prompt me "do you want to enter edit mode?" -In read-only mode, I think it would be a nice user experience to click anywhere on the graph(including on a processor) and it moves the entire graph. On the other hand, if I right click a processor and hit configure I'd like to leave read-only mode and go into edit mode. I'm not sure I'd even want to be prompted with "do you want to enter edit mode?" here since I obviously do. Dan Bress Software Engineer ONYX Consulting Services From: Mark Payne Sent: Monday, August 10, 2015 3:43 PM To: dev@nifi.apache.org Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default I'm definitely a +1. I accidentally drag processors all the time when I'm panning around a large graph. I can understand how someone would get annoyed with this, though, and I can also appreciate the desire to not start storing user preferences. However, I think we should probably at least supply a system-level configuration for whether or not to have "read-only" the default mode. Then administrators can turn it on or off, depending on the users of the system. Date: Sat, 8 Aug 2015 20:50:07 -0400 Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default From: a...@adamtaft.com To: dev@nifi.apache.org Thinking about it some more, I don't mind the concept of "read only" toggle. Maybe it's not set by default, but it could be a really easy UI element to add somewhere. Just a little slider-toggle element. [1] In theory, this might be a UI only feature, it wouldn't strictly need support in the backend api (just guessing). The logic is seemingly already there, similar user experience as non-DFMs. Anyway, +1 to the concept of read-only toggle mode. -1 for making it default, but the user interface element should be easy to work either way. Also agree that undo support might be free if versioning is added. [1] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: Ryan - the other useful case for read-only is basically when is scanning around the graph and accidentally moves a processor or relationship. By no means a big deal. The idea here was to make it explicit though that the user wishes to go into an edit mode. I do think the undo mechanism plays well and you're right that we can just focus on tightening up the delete case. Sounds like the prevailing view is to avoid read-only as a mode but rather to make it more explicit whenever we delete - and potentially move we could make more specific rather than simply them having clicked and dragged which is ambiguous with the process of panning. On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: I'm not a big fan of having a read-only mode by default. It sounds like something that would be frustrating for users when they try to make changes and then have to figure out how to switch modes. I think a clearer picture of the problem we're trying to solve would help my understanding. I'm primarily thinking of the delete case you mentioned with these comments... If we're talking about accidentally deleting processors, then the current mechanisms (IIRC) work pretty well: not deleting a running processor, one that has live incoming connections, etc. If those rules are insufficient, I would explore extending them rather than having a global read-only mode. For the case where the wrong processor is selected because it is off the screen, maybe having the confirmation pop up if anything affected wasn't displayed to confirm? That way we don't have confirmations all the time but still don't do unexpected things. I really like the idea of "undo" as well. If that is limited to processors that weren't running (because you can't delete ones that are), then that makes the undo operation easier to implement. rb On 08/08/2015 11:31 AM, Joe Witt wrote: I can dig the user pref aspect but it would mean we start storing user prefs which is a bummer. On Aug 8, 2015 1:42 PM, "Tony Kurc" wrote: Per
Re: [DISCUSS] Feature proposal: Read-only mode as default
+1 to exactly what Mark described in his last email for a system wide preference. Although I'm curious how you leave read-only mode and get into edit mode? And how do you leave edit mode and go back to read-only mode? On one hand, if I do not intend to edit the graph and I accidentally move a processor I probably don't want it to prompt me "do you want to enter edit mode?" -In read-only mode, I think it would be a nice user experience to click anywhere on the graph(including on a processor) and it moves the entire graph. On the other hand, if I right click a processor and hit configure I'd like to leave read-only mode and go into edit mode. I'm not sure I'd even want to be prompted with "do you want to enter edit mode?" here since I obviously do. Dan Bress Software Engineer ONYX Consulting Services From: Mark Payne Sent: Monday, August 10, 2015 3:43 PM To: dev@nifi.apache.org Subject: RE: [DISCUSS] Feature proposal: Read-only mode as default I'm definitely a +1. I accidentally drag processors all the time when I'm panning around a large graph. I can understand how someone would get annoyed with this, though, and I can also appreciate the desire to not start storing user preferences. However, I think we should probably at least supply a system-level configuration for whether or not to have "read-only" the default mode. Then administrators can turn it on or off, depending on the users of the system. > Date: Sat, 8 Aug 2015 20:50:07 -0400 > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > From: a...@adamtaft.com > To: dev@nifi.apache.org > > Thinking about it some more, I don't mind the concept of "read only" > toggle. Maybe it's not set by default, but it could be a really easy UI > element to add somewhere. Just a little slider-toggle element. [1] > > In theory, this might be a UI only feature, it wouldn't strictly need > support in the backend api (just guessing). The logic is seemingly already > there, similar user experience as non-DFMs. > > Anyway, +1 to the concept of read-only toggle mode. -1 for making it > default, but the user interface element should be easy to work either way. > > Also agree that undo support might be free if versioning is added. > > [1] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg > > > > > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: > >> Ryan - the other useful case for read-only is basically when is >> scanning around the graph and accidentally moves a processor or >> relationship. By no means a big deal. The idea here was to make it >> explicit though that the user wishes to go into an edit mode. >> >> I do think the undo mechanism plays well and you're right that we can >> just focus on tightening up the delete case. >> >> Sounds like the prevailing view is to avoid read-only as a mode but >> rather to make it more explicit whenever we delete - and potentially >> move we could make more specific rather than simply them having >> clicked and dragged which is ambiguous with the process of panning. >> >> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: >>> I'm not a big fan of having a read-only mode by default. It sounds like >>> something that would be frustrating for users when they try to make >> changes >>> and then have to figure out how to switch modes. >>> >>> I think a clearer picture of the problem we're trying to solve would >> help my >>> understanding. I'm primarily thinking of the delete case you mentioned >> with >>> these comments... >>> >>> If we're talking about accidentally deleting processors, then the current >>> mechanisms (IIRC) work pretty well: not deleting a running processor, one >>> that has live incoming connections, etc. If those rules are >> insufficient, I >>> would explore extending them rather than having a global read-only mode. >>> >>> For the case where the wrong processor is selected because it is off the >>> screen, maybe having the confirmation pop up if anything affected wasn't >>> displayed to confirm? That way we don't have confirmations all the time >> but >>> still don't do unexpected things. >>> >>> I really like the idea of "undo" as well. If that is limited to >> processors >>> that weren't running (because you can't delete ones that are), then that >>> makes the undo operation easier to implement. >>> >>> rb >>> >>> >>> On 08/08/2015 11:31 AM, Joe Witt wrote: I can dig the user pref aspect but it would mean we start storing user prefs which is a bummer. On Aug 8, 2015 1:42 PM, "Tony Kurc" wrote: > Personally not a fan of the idea. Maybe something analogous to >> something > like 'lock the taskbar' in Windows that can have a system default >> setting > and a user preference of on or off. > > On Sat, Aug 8, 2015 at 11:44 AM, johny casanova < > computertech2...@gmail.com> > wrote: > >> I agree it is easy to move it
RE: [DISCUSS] Feature proposal: Read-only mode as default
I'm definitely a +1. I accidentally drag processors all the time when I'm panning around a large graph. I can understand how someone would get annoyed with this, though, and I can also appreciate the desire to not start storing user preferences. However, I think we should probably at least supply a system-level configuration for whether or not to have "read-only" the default mode. Then administrators can turn it on or off, depending on the users of the system. > Date: Sat, 8 Aug 2015 20:50:07 -0400 > Subject: Re: [DISCUSS] Feature proposal: Read-only mode as default > From: a...@adamtaft.com > To: dev@nifi.apache.org > > Thinking about it some more, I don't mind the concept of "read only" > toggle. Maybe it's not set by default, but it could be a really easy UI > element to add somewhere. Just a little slider-toggle element. [1] > > In theory, this might be a UI only feature, it wouldn't strictly need > support in the backend api (just guessing). The logic is seemingly already > there, similar user experience as non-DFMs. > > Anyway, +1 to the concept of read-only toggle mode. -1 for making it > default, but the user interface element should be easy to work either way. > > Also agree that undo support might be free if versioning is added. > > [1] http://turbo.premiumpixels.com/wp-content/uploads/2011/04/preview2.jpg > > > > > On Sat, Aug 8, 2015 at 3:05 PM, Joe Witt wrote: > >> Ryan - the other useful case for read-only is basically when is >> scanning around the graph and accidentally moves a processor or >> relationship. By no means a big deal. The idea here was to make it >> explicit though that the user wishes to go into an edit mode. >> >> I do think the undo mechanism plays well and you're right that we can >> just focus on tightening up the delete case. >> >> Sounds like the prevailing view is to avoid read-only as a mode but >> rather to make it more explicit whenever we delete - and potentially >> move we could make more specific rather than simply them having >> clicked and dragged which is ambiguous with the process of panning. >> >> On Sat, Aug 8, 2015 at 2:57 PM, Ryan Blue wrote: >>> I'm not a big fan of having a read-only mode by default. It sounds like >>> something that would be frustrating for users when they try to make >> changes >>> and then have to figure out how to switch modes. >>> >>> I think a clearer picture of the problem we're trying to solve would >> help my >>> understanding. I'm primarily thinking of the delete case you mentioned >> with >>> these comments... >>> >>> If we're talking about accidentally deleting processors, then the current >>> mechanisms (IIRC) work pretty well: not deleting a running processor, one >>> that has live incoming connections, etc. If those rules are >> insufficient, I >>> would explore extending them rather than having a global read-only mode. >>> >>> For the case where the wrong processor is selected because it is off the >>> screen, maybe having the confirmation pop up if anything affected wasn't >>> displayed to confirm? That way we don't have confirmations all the time >> but >>> still don't do unexpected things. >>> >>> I really like the idea of "undo" as well. If that is limited to >> processors >>> that weren't running (because you can't delete ones that are), then that >>> makes the undo operation easier to implement. >>> >>> rb >>> >>> >>> On 08/08/2015 11:31 AM, Joe Witt wrote: I can dig the user pref aspect but it would mean we start storing user prefs which is a bummer. On Aug 8, 2015 1:42 PM, "Tony Kurc" wrote: > Personally not a fan of the idea. Maybe something analogous to >> something > like 'lock the taskbar' in Windows that can have a system default >> setting > and a user preference of on or off. > > On Sat, Aug 8, 2015 at 11:44 AM, johny casanova < > computertech2...@gmail.com> > wrote: > >> I agree it is easy to move it delete something by mistake. Some flows >> are >> huge or are using,more resources and are slower to load and you can >> accidently do something by mistake. I believe the "are yous sure u >> want > > to >> >> delete?" its a good start. >> On Aug 7, 2015 10:31 PM, "Joe Witt" wrote: >> >>> Team, >>> >>> We've been hearing from users of nifi that it is too easy to >>> accidentally move something on the flow or delete large portions of >>> the flow. This is the case when panning the screen for example and >>> accidentally having a processor selected instead. >>> >>> What is worth consideration then is the notion of making the flow >>> 'read-only' by default. In this case the user would need to >>> explicitly 'enable edit mode'. We would then also support a >>> confirmation dialog or similar construct whenever deleting components >>> on the flow. >>> >>> Anyone have a strong objection to this concept? If so, do y
RE: Help required with my custom controller service
Brandon,
I've seen this occur when I forgot to add a dependency on the
ssl-context-service-api-nar in my NAR's pom.
You should have something like:
org.apache.nifi
ssl-context-service-api
0.3.0-SNAPSHOT
nar
Is that by chance the issue, or is there something else going on?
Thanks
-Mark
> From: b...@jhu.edu
> Date: Mon, 10 Aug 2015 19:13:50 +
> Subject: Re: Help required with my custom controller service
> To: dev@nifi.apache.org
>
> All,
>
> Was this ever solved / explained? I'm having a similar issue. If there's
> a simple answer that I'm missing that would be great... otherwise I might
> post an example set of NARs somewhere tomorrow. Probably the simplest
> question first is, if I want to create a custom processor that uses a
> SSLContextService, what dependencies do I need to add where (assuming we're
> using the processor NAR archetype)? I've created an example that compiles,
> loads in NiFi, and can be dropped on the graph. However, it can not be
> configured to use any currently existing SSLContextService, and any that
> are created have the same UUID issue described by David. Thoughts?
>
> Brandon
>
>
>
> On Tue, Jul 28, 2015 at 10:50 AM Mark Payne wrote:
>
>> Dave,
>>
>> In addition to the points that Aldrin brought up, are your CacheService
>> interface
>> and StandardCacheService classes in the same NAR?
>>
>> If they are not in the same NAR, does your NAR for StandardCacheService
>> have a Maven dependency
>> on the NAR that houses CacheService?
>>
>> Thanks
>> -Mark
>>
>>
>>> From: aldrinp...@gmail.com
>>> Date: Mon, 27 Jul 2015 23:26:58 -0400
>>> Subject: Re: Help required with my custom controller service
>>> To: dev@nifi.apache.org; davidrsm...@btinternet.com
>>>
>>> Dave,
>>>
>>> Some quick notes as I work through your setup.
>>>
>>> Did you create an entry in your
>>> NAR's org.apache.nifi.controller.ControllerService file? This would be in
>>> src/main/resources/META-INF/services directory of your project. It seems
>>> like this isn't likely the case, but a point that can sometimes get
>>> overlooked.
>>>
>>> Your accessing of the service property in your processor looks good.
>>>
>>> Did you accidentally override AbstractControllerService#getIdentifier()?
>>> It seems like this could lead to the error you are seeing, but it is hard
>>> to be sure.
>>>
>>> If you are able to share more code with us, we can provide some more
>>> pointed assistance. Have you managed to get your processor and controller
>>> service running within the test framework [1]? If not, I would suggest
>>> doing so to cut down on iterations in debugging your problems as well as
>>> providing a means for you to easily step through the code.
>>>
>>> [1]
>> http://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#testing
>>>
>>> On Sun, Jul 26, 2015 at 4:45 PM, DAVID SMITH >>
>>> wrote:
>>>
Hi
I have been trying to write a simple Cache Controller Service that uses
>> a
Map to hold key/value pairs. I am using
nifi-0.1.0-incubating. I have created an Interface called CacheService
which extends ControllerService.public interface CacheService extends
ControllerService {
I have created an implementation called StandardCacheService which is as
follows:
public class StandardCacheService extends AbstractControllerService
implements CacheService {
I have compiled the StandardCacheService and created a nar which I have
then put into my NiFi lib directory, my StandardCacheService Controller
Service appears in the Controller services tab of the NiFi Flow Settings
panel, I can edit it and enable it. Also there are no abnormal log
>> messages.
However, when I try to configure the CacheService in my test Processor,
again I get no errors but when I cannot see my StandardCacheService. My
processor has the following snippets to implement the Cache
Service/Controller:
public static final PropertyDescriptor CACHE_SERVICE = new
PropertyDescriptor.Builder()
.name("Cache Service")
.description("The Controller Service to use in order to obtain a
Cache Service")
.required(false)
.identifiesControllerService(CacheService.class)
.build();
final CacheService cache =
>> context.getProperty(CACHE_SERVICE).asControllerService(CacheService.class);
When configuring the processor, the 'Cache Service' drop down doesn't
>> show
a populated list showing my StandardCacheService, but it does allow me
>> to
create a new service, the resulting panel allows me to then select
StandardCacheService. When I select 'create' I get a UUID value in the
Value property of the Configure Processor panel. When I then apply this
the processor shows a yellow triangle, when I hover over it I get the
following message:
'Cache Service validated against is invalid
Re: Instantiating a Controller Service in a Junit test
Mark
Thanks for the information, it works a treat.
Dave
On Monday, 10 August 2015, 1:12, Mark Payne wrote:
David,
Yes, you'll also need to set the controller service in your processor. Sorry, I
forgot to mention that.
So after the call to runner.enableControllerService(), and before the call to
runner.run(), you would do:
runner.setProperty(CacheTester.CACHE_SERVICE, "my-cache");
This way, the CacheTester processor knows to reference that controller service.
So your method will look like:
@Test
public void checkCache() throws InitializationException, IOException{
final TestRunner runner = TestRunners.newTestRunner(CacheTester.class);
final StandardCacheService cacheService = new StandardCacheService();
runner.addControllerService("my-cache", cacheService);
runner.setProperty(cacheService, StandardCacheService.DATAFILE,
"/data/TEST_FILE");
runner.setProperty(CacheTester.CACHE_SERVICE, "my-cache");
runner.enableControllerService(cacheService);
runner.run();
}
Thanks
-Mark
> Date: Sun, 9 Aug 2015 21:06:18 +
> From: davidrsm...@btinternet.com
> To: dev@nifi.apache.org
> Subject: Re: Instantiating a Controller Service in a Junit test
>
> Mark
> Thanks for the reply, I have changed my test as you suggested, see below:
> @Test
> public void checkCache() throws InitializationException, IOException{
> final TestRunner runner = TestRunners.newTestRunner(CacheTester.class);
> final StandardCacheService cacheService = new StandardCacheService();
> runner.addControllerService("my-cache", cacheService);
> runner.setProperty(cacheService, StandardCacheService.DATAFILE,
> "/data/TEST_FILE");
> runner.enableControllerService(cacheService);
> runner.run();
> }
>
>
> When I run my test I now get a null pointer exception in my CacheTester
> class. It appears the cache in my CacheTester class doesn't exist, when I
> comment out all the calls to the cache methods the test passes.
> If I understand the code above correctly I don't believe I have set the
> PropertyDescriptor in my CacheTester processor class which is shown below has
> been set, am I correct?:
> public static final PropertyDescriptor CACHE_SERVICE = new
> PropertyDescriptor.Builder() .name("Cache Service") .description("The
> Controller Service to use in order to obtain a Cache Service")
> .required(false) .identifiesControllerService(CacheServiceAPI.class) .build();
>
>
> BTW, the former I mentioned in my original post was referring to the
> descriptions I had given about how to instantiate the Controller Service.
> Many thanksDave
>
>
> On Sunday, 9 August 2015, 21:05, Mark Payne wrote:
>
>
> Hi David,
>
> You should be able to just import your StandardCacheService in your unit test.
>
> You can then instantiate the controller service and use
> TestRunner.addControllerService, as you're doing here.
> At that point, to set the properties, you can use TestRunner.setProperty. For
> example:
>
> final StandardCacheService cacheService = new StandardCacheService();
> runner.addControllerService("my-cache", cacheService);
> runner.setProperty(cacheService, StandardCacheService.DATAFILE, "/data/file");
> runner.enableControllerService(cacheService);
>
> There is no need to actually create the Logger and call initialize, as that
> is handled for you when you call TestRunner.addControllerService.
>
> In your message, can you explain a bit further what you meant by
> "If the former is correct how do I set the PropertyDescriptor as when I did
> try this option the StandardCacheService.DATAFILE PropertyDescriptor was
> never visible?"
>
> It's important that you not mark the PropertyDescriptor as private, or else
> you won't be able to access it, and you'll also want to ensure that
> it is returned by your getSupportedPropertyDescriptors() method. If I am
> misunderstanding the comment, please advise.
>
> Let me know if this clears things up for you, or if you need any more details.
>
> If anything doesn't make sense, just give a shout - we're always happy to
> help! :)
>
> Thanks
> -Mark
>
>
>
>> Date: Sun, 9 Aug 2015 14:40:53 +
>> From: davidrsm...@btinternet.com
>> To: dev@nifi.apache.org
>> Subject: Instantiating a Controller Service in a Junit test
>>
>> Hi
>> I have written a simple Cache Controller Service, this Controller Service
>> has a property which if populated allows the cache to be populated when it
>> is intialized. I have also written a simple processor that allows me to
>> utilize the Controller Service and checks some of the preloaded values and
>> also checks some of the cache methods.
>> I now want to write some Junit tests for my processor, and I want to
>> instantiate my Cache Controller Service. I have looked at other Junit test
>> classes in the nifi-0.2.1 source release for some guidance on how to do
>> this, looking particularly at the test classes for the DetectDuplicate
>> processor.
Re: Help required with my custom controller service
All,
Was this ever solved / explained? I'm having a similar issue. If there's
a simple answer that I'm missing that would be great... otherwise I might
post an example set of NARs somewhere tomorrow. Probably the simplest
question first is, if I want to create a custom processor that uses a
SSLContextService, what dependencies do I need to add where (assuming we're
using the processor NAR archetype)? I've created an example that compiles,
loads in NiFi, and can be dropped on the graph. However, it can not be
configured to use any currently existing SSLContextService, and any that
are created have the same UUID issue described by David. Thoughts?
Brandon
On Tue, Jul 28, 2015 at 10:50 AM Mark Payne wrote:
> Dave,
>
> In addition to the points that Aldrin brought up, are your CacheService
> interface
> and StandardCacheService classes in the same NAR?
>
> If they are not in the same NAR, does your NAR for StandardCacheService
> have a Maven dependency
> on the NAR that houses CacheService?
>
> Thanks
> -Mark
>
>
> > From: aldrinp...@gmail.com
> > Date: Mon, 27 Jul 2015 23:26:58 -0400
> > Subject: Re: Help required with my custom controller service
> > To: dev@nifi.apache.org; davidrsm...@btinternet.com
> >
> > Dave,
> >
> > Some quick notes as I work through your setup.
> >
> > Did you create an entry in your
> > NAR's org.apache.nifi.controller.ControllerService file? This would be in
> > src/main/resources/META-INF/services directory of your project. It seems
> > like this isn't likely the case, but a point that can sometimes get
> > overlooked.
> >
> > Your accessing of the service property in your processor looks good.
> >
> > Did you accidentally override AbstractControllerService#getIdentifier()?
> > It seems like this could lead to the error you are seeing, but it is hard
> > to be sure.
> >
> > If you are able to share more code with us, we can provide some more
> > pointed assistance. Have you managed to get your processor and controller
> > service running within the test framework [1]? If not, I would suggest
> > doing so to cut down on iterations in debugging your problems as well as
> > providing a means for you to easily step through the code.
> >
> > [1]
> http://nifi.apache.org/docs/nifi-docs/html/developer-guide.html#testing
> >
> > On Sun, Jul 26, 2015 at 4:45 PM, DAVID SMITH >
> > wrote:
> >
> >> Hi
> >> I have been trying to write a simple Cache Controller Service that uses
> a
> >> Map to hold key/value pairs. I am using
> >> nifi-0.1.0-incubating. I have created an Interface called CacheService
> >> which extends ControllerService.public interface CacheService extends
> >> ControllerService {
> >>
> >> I have created an implementation called StandardCacheService which is as
> >> follows:
> >> public class StandardCacheService extends AbstractControllerService
> >> implements CacheService {
> >> I have compiled the StandardCacheService and created a nar which I have
> >> then put into my NiFi lib directory, my StandardCacheService Controller
> >> Service appears in the Controller services tab of the NiFi Flow Settings
> >> panel, I can edit it and enable it. Also there are no abnormal log
> messages.
> >> However, when I try to configure the CacheService in my test Processor,
> >> again I get no errors but when I cannot see my StandardCacheService. My
> >> processor has the following snippets to implement the Cache
> >> Service/Controller:
> >> public static final PropertyDescriptor CACHE_SERVICE = new
> >> PropertyDescriptor.Builder()
> >> .name("Cache Service")
> >> .description("The Controller Service to use in order to obtain a
> >> Cache Service")
> >> .required(false)
> >> .identifiesControllerService(CacheService.class)
> >> .build();
> >>
> >> final CacheService cache =
> >>
> context.getProperty(CACHE_SERVICE).asControllerService(CacheService.class);
> >>
> >>
> >>
> >>
> >> When configuring the processor, the 'Cache Service' drop down doesn't
> show
> >> a populated list showing my StandardCacheService, but it does allow me
> to
> >> create a new service, the resulting panel allows me to then select
> >> StandardCacheService. When I select 'create' I get a UUID value in the
> >> Value property of the Configure Processor panel. When I then apply this
> >> the processor shows a yellow triangle, when I hover over it I get the
> >> following message:
> >> 'Cache Service validated against is invalid because Invalid
> >> Controller service is not a valid Controller service Identifier
> or
> >> does not reference the correct type of Controller service.'
> >> Can you help please
> >> Many thanksDave
> >>
> >>
>
Re: eliminate nifi-parent, split out nifi-nar-maven-plugin, have nifi in its own tree
+1 I think separate git repos is a great idea. One thing to clarify, too: most of the time the nifi project relies on the last nifi-nar-maven-plugin release, right? So that should be transparent for most people building the project. It would only be awkward for someone updating the maven plugin and testing it out locally because the develop branch should always track a release. Speaking of the develop branch... what about using master like most projects after this change? rb On 08/10/2015 07:32 AM, Joe Witt wrote: Team, We've seen and heard the confusion of folks trying to build NiFi's goofy three step build process with parent, nar plugin, and nifi. I propose to do the following: 1) Eliminate the nifi-parent by pushing anything necessary back into nifi-nar-maven-plugin. The DRY concept is valid but just not worth a third project at this point given how little it avoids meaningful repetition on. 2) Create a new apache git repo for 'nifi-maven-plugins' and move the 'nifi-nar-maven-plugin' content into it. 3) Remove the nifi-parent and nifi-nar-maven-plugin from nifi folder and promote the current 'nifi' sub folder to the top level. Why: Folks are confused as to why they need to build all three and it is odd that in a given project folder you would have to each manually. It is just not a generally appreciated fact that you cannot have a dependency on a maven plugin within the same reactor build that uses that builds that plugin. By cleaning this up people can just download the source and build it. We don't have to have any protracted build cycles for 'nifi maven plugings' anymore leaving dependency on a snapshot in the nifi tree. If there seems to be consensus on this i'll put in the infra ticket soon. Thanks Joe -- Ryan Blue Software Engineer Cloudera, Inc.
documented a series of nifi feature design/proposals
Here is where folks can find more information about features/design proposals. This may be a better way for collaboration and fine tuning on those ideas. https://cwiki.apache.org/confluence/display/NIFI/NiFi+Feature+Proposals Thanks Joe
Re: [DISCUSS] Feature proposal: "Function Groups" and wormholes
Wormhole writeup: https://cwiki.apache.org/confluence/display/NIFI/Wormhole+Connections Function Group writeup: https://cwiki.apache.org/confluence/display/NIFI/Reference-able+Process+Groups On Mon, Aug 10, 2015 at 10:41 AM, Joe Witt wrote: > Mike > > "Wormholes sounds functionally similar to JMS Queues with topic > subscriptions?" > Yep - you've got it. Though we'd still make it easy for folks to > understand the directionality of the flow because we don't want to > lose that. > > > Function Groups: Yeah i can't believe we didn't really come up with > this before now. It was inspired by the wormhole concept. These > would be crazy useful. > > > > Thanks > Joe > > On Mon, Aug 10, 2015 at 10:36 AM, Mike Drob wrote: >> Wormholes sounds functionally similar to JMS Queues with topic >> subscriptions? Function groups are something I've wished for before but >> didn't think it was possible. >> >> On Sun, Aug 9, 2015 at 8:27 AM, Joe Witt wrote: >> >>> Toivo >>> >>> I think from your response you did understand it quite well. I'll try >>> to turn this and a series of other features/concepts into a series of >>> wiki pages so it can be more readily consumed, improved, and commented >>> on. >>> >>> Thanks >>> Joe >>> >>> On Sun, Aug 9, 2015 at 8:04 AM, Toivo Adams wrote: >>> > Not sure I understand 'wormhole' concept correctly. >>> > >>> > We use a lot of request-response type of processing. >>> > Processing pipeline contain several processors. >>> > Processing is done mostly sequentially (and same parts parallel). >>> > During processing anything can happen. But our goal is to send always >>> > responds back. >>> > In case of errors response contains errors data. >>> > >>> > There can be different types of problems; some are warnings, some >>> notices, >>> > some errors and some fatal errors. >>> > >>> > In case of fatal errors we stop processing automatically and jump >>> directly >>> > to so called ‘error flow’. (subflow) >>> > Error flow responsibility is to create response which contains errors and >>> > send response back to requestor. >>> > Error flow may also contain some special purpose processors – collect >>> some >>> > data for report, alert monitoring, etc. >>> > >>> > Now 'wormhole' is very helpful. It’s annoying to add explicit >>> connections to >>> > all business processors. Also this reduces readability. >>> > For us flow should readable and understandable from business point of >>> view. >>> > And low level technical behavior should be handled ‘behind the scenes’. >>> > Ideally business processors should not have ‘redirect to error flow’ >>> output >>> > (relationship) at all. >>> > >>> > At the same time I think 'wormhole' should be used very carefully. Only >>> when >>> > really needed. >>> > Otherwise it may be source of weird bugs and it is hard to follow what is >>> > going on. >>> > >>> > >>> > Thanks >>> > toivo >>> > >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/DISCUSS-Feature-proposal-Function-Groups-and-wormholes-tp2381p2391.html >>> > Sent from the Apache NiFi (incubating) Developer List mailing list >>> archive at Nabble.com. >>>
eliminate nifi-parent, split out nifi-nar-maven-plugin, have nifi in its own tree
Team, We've seen and heard the confusion of folks trying to build NiFi's goofy three step build process with parent, nar plugin, and nifi. I propose to do the following: 1) Eliminate the nifi-parent by pushing anything necessary back into nifi-nar-maven-plugin. The DRY concept is valid but just not worth a third project at this point given how little it avoids meaningful repetition on. 2) Create a new apache git repo for 'nifi-maven-plugins' and move the 'nifi-nar-maven-plugin' content into it. 3) Remove the nifi-parent and nifi-nar-maven-plugin from nifi folder and promote the current 'nifi' sub folder to the top level. Why: Folks are confused as to why they need to build all three and it is odd that in a given project folder you would have to each manually. It is just not a generally appreciated fact that you cannot have a dependency on a maven plugin within the same reactor build that uses that builds that plugin. By cleaning this up people can just download the source and build it. We don't have to have any protracted build cycles for 'nifi maven plugings' anymore leaving dependency on a snapshot in the nifi tree. If there seems to be consensus on this i'll put in the infra ticket soon. Thanks Joe
Re: [DISCUSS] Feature proposal: "Function Groups" and wormholes
Mike "Wormholes sounds functionally similar to JMS Queues with topic subscriptions?" Yep - you've got it. Though we'd still make it easy for folks to understand the directionality of the flow because we don't want to lose that. Function Groups: Yeah i can't believe we didn't really come up with this before now. It was inspired by the wormhole concept. These would be crazy useful. Thanks Joe On Mon, Aug 10, 2015 at 10:36 AM, Mike Drob wrote: > Wormholes sounds functionally similar to JMS Queues with topic > subscriptions? Function groups are something I've wished for before but > didn't think it was possible. > > On Sun, Aug 9, 2015 at 8:27 AM, Joe Witt wrote: > >> Toivo >> >> I think from your response you did understand it quite well. I'll try >> to turn this and a series of other features/concepts into a series of >> wiki pages so it can be more readily consumed, improved, and commented >> on. >> >> Thanks >> Joe >> >> On Sun, Aug 9, 2015 at 8:04 AM, Toivo Adams wrote: >> > Not sure I understand 'wormhole' concept correctly. >> > >> > We use a lot of request-response type of processing. >> > Processing pipeline contain several processors. >> > Processing is done mostly sequentially (and same parts parallel). >> > During processing anything can happen. But our goal is to send always >> > responds back. >> > In case of errors response contains errors data. >> > >> > There can be different types of problems; some are warnings, some >> notices, >> > some errors and some fatal errors. >> > >> > In case of fatal errors we stop processing automatically and jump >> directly >> > to so called ‘error flow’. (subflow) >> > Error flow responsibility is to create response which contains errors and >> > send response back to requestor. >> > Error flow may also contain some special purpose processors – collect >> some >> > data for report, alert monitoring, etc. >> > >> > Now 'wormhole' is very helpful. It’s annoying to add explicit >> connections to >> > all business processors. Also this reduces readability. >> > For us flow should readable and understandable from business point of >> view. >> > And low level technical behavior should be handled ‘behind the scenes’. >> > Ideally business processors should not have ‘redirect to error flow’ >> output >> > (relationship) at all. >> > >> > At the same time I think 'wormhole' should be used very carefully. Only >> when >> > really needed. >> > Otherwise it may be source of weird bugs and it is hard to follow what is >> > going on. >> > >> > >> > Thanks >> > toivo >> > >> > >> > >> > >> > -- >> > View this message in context: >> http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/DISCUSS-Feature-proposal-Function-Groups-and-wormholes-tp2381p2391.html >> > Sent from the Apache NiFi (incubating) Developer List mailing list >> archive at Nabble.com. >>
Re: [DISCUSS] Feature proposal: "Function Groups" and wormholes
Wormholes sounds functionally similar to JMS Queues with topic subscriptions? Function groups are something I've wished for before but didn't think it was possible. On Sun, Aug 9, 2015 at 8:27 AM, Joe Witt wrote: > Toivo > > I think from your response you did understand it quite well. I'll try > to turn this and a series of other features/concepts into a series of > wiki pages so it can be more readily consumed, improved, and commented > on. > > Thanks > Joe > > On Sun, Aug 9, 2015 at 8:04 AM, Toivo Adams wrote: > > Not sure I understand 'wormhole' concept correctly. > > > > We use a lot of request-response type of processing. > > Processing pipeline contain several processors. > > Processing is done mostly sequentially (and same parts parallel). > > During processing anything can happen. But our goal is to send always > > responds back. > > In case of errors response contains errors data. > > > > There can be different types of problems; some are warnings, some > notices, > > some errors and some fatal errors. > > > > In case of fatal errors we stop processing automatically and jump > directly > > to so called ‘error flow’. (subflow) > > Error flow responsibility is to create response which contains errors and > > send response back to requestor. > > Error flow may also contain some special purpose processors – collect > some > > data for report, alert monitoring, etc. > > > > Now 'wormhole' is very helpful. It’s annoying to add explicit > connections to > > all business processors. Also this reduces readability. > > For us flow should readable and understandable from business point of > view. > > And low level technical behavior should be handled ‘behind the scenes’. > > Ideally business processors should not have ‘redirect to error flow’ > output > > (relationship) at all. > > > > At the same time I think 'wormhole' should be used very carefully. Only > when > > really needed. > > Otherwise it may be source of weird bugs and it is hard to follow what is > > going on. > > > > > > Thanks > > toivo > > > > > > > > > > -- > > View this message in context: > http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/DISCUSS-Feature-proposal-Function-Groups-and-wormholes-tp2381p2391.html > > Sent from the Apache NiFi (incubating) Developer List mailing list > archive at Nabble.com. >
RE: NiFi Flow Usage questions
Hi Eric, The REST API provides a great deal of power for manipulating flows, by creating/updating/deleting components and for obtaining information such as metrics about the components on the graph. The REST API doesn't provide any ability, though, to access FlowFiles from outside of NiFi. FlowFile access (content and attributes) is intended to be done only through the Processors that are added to the flow. Currently, the capability to impact a FlowFile based on other FlowFiles (e.g., children) isn't present. However, this is something that is being worked on ticket NIFI-190 [1]. Once this ticket is complete, you should be able to "hold" a FlowFile while you process its children, and then once the children have completed processing, the flow can be notified to release the original FlowFile, optionally passing some attributes to the original, so that you can make routing decisions, etc. There are certainly mechanisms for packaging FlowFiles with their attributes and contents. If you are transferring the data directly from one NiFi to another, this can be accomplished by using site-to-site to transfer the data between instances. Unfortunately, it looks like the site-to-site information is not documented much at all in the User Guide, so I have created a ticket for that, as well [2]. This is really the preferred method for transferring data between two NiFi instances, as it will automatically detect clusters and perform load balancing. Alternatively, the PostHTTP/ListenHTTP processors to pass the data and configuring the PostHTTP to include attributes. If you are not sending the data directly to another NiFi but have some sort of intermediary step, you can package the FlowFiles with their contents by using MergeContent. If you need each FlowFile packaged separately, you can do that by setting both the min and max entries to 1. Otherwise, you can package multiple together into a single file. For the Merge Strategy, use the Bin-Packing Algorithm and for the Merge Format, choose the "FlowFile Stream, v3". Sorry, these are some fairly long-winded answers, but I wanted to ensure that I didn't leave you with more questions than answers :) If anything isn't clear, please let me know! Thanks -Mark [1] https://issues.apache.org/jira/browse/NIFI-190 [2] https://issues.apache.org/jira/browse/NIFI-832 > Date: Sun, 9 Aug 2015 22:30:49 -0400 > Subject: NiFi Flow Usage questions > From: edcros...@gmail.com > To: dev@nifi.apache.org > > Do you have an example workflow of a REST API or external program that > reads the flowfile contents and update attributes with the output? > > Can you have processors for child flows impact original flow? > -Compressed file is input into system > -Unpack file > -Run all children files through external program > -Make decision on original based on children attributes > > Last and not least- > Is there a way to export and import attributes between different Nifi > instances? You could have uuid.attributes and uuid.file to match them on > the distance end. > > Thoughts? > > Thank you, > Eric
