1 2 Previous Next 17 Replies Latest reply on Jul 28, 2008 10:21 AM by tom.baeyens Go to original post
      • 15. Re: Support of variable in timerDefinition
        tom.baeyens

        DB tests should be named XxxxDbTest

        • 16. Re: Support of variable in timerDefinition
          pascal.verdage

          First of all, I have neglected the javadoc and explanations so I apologize.

          can you explain the patch a bit more ?

          The goal of this patch is to allow variables and more generally scripting expressions to create a timer. In the PVM, timers are created at runtime from a TimerDefinition. Nodes and processes can have timer definitions.
          Previously, the definitions contained several parameters and there was two ways to describe a timer's dueDate : a Date object or a String representing a Duration.
          As discussed in this thread, I replaced those two parameters (dueDate and dueDateDescription) by two others: an expression and an expression language.
          Especially the change from setDueDateDescription to getDateFromDuration(String expression) in TimerImpl

          setDueDateDescription is called when the timer is created. The argument is the expression in TimerDefinition. This method sets the due date from the expression.
          The expression is evaluated, using the ScriptManager, in an expression language (the timer's one or the default one if null) then the result is analyzed.
          If the expression is a variable name, the evaluation returns its content. If it is unknown, the evaluation returns the expression.

          The returned object is filtered:
          - if it is a Date object, the dueDate is immediately set
          - if it is a String, it can be a formatted date (the default format is 'yyyy-MM-dd HH:mm:ss,SSS' or a duration.
          The method getDueDateFromDuration is a static helper method to get a date from a string. This method factorize some code and should make setDueDateDescription easier to read.

          If the evaluated expression is a string, at most one of the tries doesn't create an exception. After the evaluation, if a date has been created it is set else the last exception caught exception is rethrown.

          I also saw you added NPE's to JobTestTimerSession. While this does not hurt, the real check should be done in when the JobTestTimerSession is wired. That is where it becomes obvious that a JobTestTimerSession is created while a hibernate session is not available.

          I did that while working on non persisted tests. Using the test TimerSession in non persisted mode launched an exception and I thought it shouldn't so I changed it.
          If you think it is inappropriate, you (or I) can revert it. The mentioned non persisted tests no longer exist but, as I said, I thought it was good to allow the non persisted mode. Still, I should have committed it separately.

          what is the JobTestTimerSession doing in the main sources ?

          I think it was you who put it there (please excuse me if I'm wrong). The environment can declare <timer-session target="test" />. The parsing and binding are in the main sources so the java file has to be there to.

          Now I have to try and reverse engineer those 3 things from the code updates
          I thought from the discussion that this modification was good. If you really think that it should be reversed, I can try to do it if you prefer.

          • 17. Re: Support of variable in timerDefinition
            tom.baeyens

             

            "pascal.verdage" wrote:
            First of all, I have neglected the javadoc and explanations so I apologize.
            can you explain the patch a bit more ?

            The goal of this patch is to allow variables and more generally scripting expressions to create a timer. In the PVM, timers are created at runtime from a TimerDefinition. Nodes and processes can have timer definitions.
            Previously, the definitions contained several parameters and there was two ways to describe a timer's dueDate : a Date object or a String representing a Duration.
            As discussed in this thread, I replaced those two parameters (dueDate and dueDateDescription) by two others: an expression and an expression language.


            (No apologies needed)

            This describes the actual change. But I didn't yet understand what why the previous situation was not good. Nor do I know if you understand the goals of the 2 separate members that were present before.

            - Date was introduced for a fixed dueDate
            - dueDateDescription was in case a duration needed to be calculated

            One of those two needed to be specified.

            I'll revert the commit and try to create a patch file with your changes. Please make sure that Guillaume can make your case. I'll discuss with him in Turnhout. Then we can decide here in turnhout if we re-apply the patch or not.

            1 2 Previous Next