Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.5.0
    • Labels:
      None
    • Environment:

      Activity

      Hide
      Matthieu Morel added a comment -

      Indeed, I hadn't considered the trigger evaluation...

      In the current implementation, triggers depend on the type of incoming events, and are configured during the initialization of the application.

      I added a method that checks whether incoming events have corresponding triggers, based on the runtime type of the event. If there is no match, then no dispatch to trigger methods will be performed (an inactive trigger is added to the corresponding map structure)

      If there is a match, i.e. the incoming event has a configured event trigger, then it is evaluated, and if evaluated to true, dispatched to the relevant onTrigger method.

      I added a pull request https://github.com/leoneu/s4-piper/pull/3

      Question:
      I wonder about the usefulness of parameterizable onTrigger methods? Is it really worth providing that or couldn't we just have a single onTrigger() method?

      Show
      Matthieu Morel added a comment - Indeed, I hadn't considered the trigger evaluation... In the current implementation, triggers depend on the type of incoming events, and are configured during the initialization of the application. I added a method that checks whether incoming events have corresponding triggers, based on the runtime type of the event. If there is no match, then no dispatch to trigger methods will be performed (an inactive trigger is added to the corresponding map structure) If there is a match, i.e. the incoming event has a configured event trigger, then it is evaluated, and if evaluated to true, dispatched to the relevant onTrigger method. I added a pull request https://github.com/leoneu/s4-piper/pull/3 Question: I wonder about the usefulness of parameterizable onTrigger methods? Is it really worth providing that or couldn't we just have a single onTrigger() method?
      Hide
      Leo Neumeyer added a comment -

      Answer to your question: If PE has several incoming event types, how do you bind a specific type to onTrigger(). Also, this seems symmetric with onEvent(), developer only needs to learn one pattern for both cases.

      Show
      Leo Neumeyer added a comment - Answer to your question: If PE has several incoming event types, how do you bind a specific type to onTrigger(). Also, this seems symmetric with onEvent(), developer only needs to learn one pattern for both cases.
      Hide
      Leo Neumeyer added a comment -

      I changed test io.s4.wordcount.WordCounterPE to use an onTrigger() method to make sure the test case fails until the eventTrigger matching code is fixed in App. I noticed that the test doesn't exit on failure, I think this is also a bug.

      Show
      Leo Neumeyer added a comment - I changed test io.s4.wordcount.WordCounterPE to use an onTrigger() method to make sure the test case fails until the eventTrigger matching code is fixed in App. I noticed that the test doesn't exit on failure, I think this is also a bug.
      Hide
      Leo Neumeyer added a comment -

      I missed your earlier pull request, sorry about that. The isTrigger method in ProcessingElement is pretty neat! Merged done.

      Show
      Leo Neumeyer added a comment - I missed your earlier pull request, sorry about that. The isTrigger method in ProcessingElement is pretty neat! Merged done.
      Hide
      Leo Neumeyer added a comment -

      We are in sync now.

      Show
      Leo Neumeyer added a comment - We are in sync now.

        People

        • Assignee:
          Matthieu Morel
          Reporter:
          Leo Neumeyer
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development