hi John,
in my rule bases, I have actually 1-2 cases of Jump rules with 'continue'
set to non-default value. These cases do not come up very often, but one
scenario might be an event which belongs into several classes. When you
have two consecutive Jump rules for processing two event classes that have
overlaps, having 'continue' set to TakeNext in the first Jump rule passes
events from first class to the second Jump rule. This rule can verify if
the event also belongs to second class, and submit it to relevant cfset if
needed. Of course, this scenario can be implemented by setting up two
configuration files, each containing one Jump rule -- but if one would like
to have one (or few) configuration files for Jump rules, continue=TakeNext
(or perhaps continue=Goto) is actually helpful.
kind regards,
risto
2015-04-07 2:28 GMT+03:00 John P. Rouillard <rou...@cs.umb.edu>:
>
> Hi Risto:
>
> In message
> <cagfjscmrt8uofkvl3dxdlvozhr8_s349f1c7kk_hwhakvgh...@mail.gmail.com>,
> Risto Vaarandi writes:
> >2015-04-06 22:41 GMT+03:00 Leonard Lawton <leonard.law...@gmail.com>:
> >> I tried this:
> >>
> >> main.conf:
> >> [...]type=Options
> >> joincfset=returnfromjumps
> >> procallin=no
> >>
> >> type=Jump
> >> ptype=RegExp
> >> pattern=ASA
> >> cfset=firewall-events
> >>
> >> label=returnfromjumpslabel
> >>
> >> join.conf
> >>
> >> type=Options
> >> procallin=no
> >> joincfset=firewall-events
> >>
> >> type=Jump
> >> ptype=RegExp
> >> pattern=.?
> >> cfset=returnfromjumps
> >> continue=goto returnfromjumpslabel
> >>
> >> But I get "label returnfromjumpslabel does not exist, assuming
> >> continue=DontCont" when restarting syslog.
> >...you are seeing this message, since "goto" can be used for moving
> >to a label within the *same* rule file, but in your case
> >"returnfromjumpslabel" is in a different file.
>
> Hmm, I skimmed the Jump Rule entry on the man page before I came up
> with the jump/goto idea. Labels being restricted to only the same file
> is sort of implied much earlier in the man page by:
>
> GoTo <label> after an event has matched the rule, search for matching
> rules will continue from the location of <label> in the
> configuration file (<label> must be defined with the label keyword
> anywhere in the configuration file *after* the current rule
> definition)
>
> Given the label restriction, does the Jump rule need to support
> continue at all? I don't think it makes any sense since:
>
> continue = takenext
> makes no sense as the jump rule is going to move to the first
> rule in the cfset not the next rule in the current file
> continue = goto <label>
> also makes no sense since the label isn't valid in a different
> file
> continue = dontcont
> the jump implies dontcont anyway
> continue = EndMatch
> the jump is useless since the event will be discarded
> and a new event started
>
> Am I correct about the continue settings, or is there some interaction
> with cfset/continue I am missing?
>
> Also I think a jump operation without a cfset can be replaced by a
> Single rule with no change in operation (which IIRC didn't used to be
> the case but is now).
>
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
