1 2 Previous Next 17 Replies Latest reply on Jul 28, 2008 10:21 AM by tom.baeyens

    Support of variable in timerDefinition

    pascal.verdage

      Hi,

      As it has already been discussed in the post on Expression Language0 (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155029#4155029), support of variables in timerDefinition would allow more flexibility in the use of timers.

      "kukeltje" wrote:
      - setting timers dynamically based on processvariables
      - choosing a specific subprocess runtime instead of designtime

      Furthermore, this is promoted in specifications. In BPEL-2.0, specification of the Wait activity (http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html#_Toc164738509) explains that:
      A typical use of this activity is to invoke an operation at a certain time (in this example a constant, but more typically an expression dependent on process state)

      Dependent on process state means to my mind using a variable.

      Plus, this feature is blocking to use TimerDefinition in Orchestra since this is the more common way Pick and Wait activities are used. So we still create timers at runtime.

      Do you think it would be possible to add this feature to the pvm: using process (or node) variables to define a timer's dueDate?
      Or should this wait until the expression language is supported (as you said, in the future ;))

      Regards,
      Pascal

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

          it is certainly something I want to consider.

          what expression language are you thinking about ?

          how would you want to express the due date in such a timer definition ?

          as long as this is not supported, you can always create the timers programmatically.

          • 2. Re: Support of variable in timerDefinition
            kukeltje

             

            what expression language are you thinking about ?


            I'd go for the Business Process Expression Language... ;-)

            No seriously... you mean Unified EL or something else?

            Isn't using a processvariable as simple as making a processvariableresolver and register that while putting the duedate value through this a parser?

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

               

              "kukeltje" wrote:
              No seriously... you mean Unified EL or something else?

              Isn't using a processvariable as simple as making a processvariableresolver and register that while putting the duedate value through this a parser?


              yes. if that is what is wanted, then it is easy.

              but i would be surprised if BPEL used UEL as its expression language.

              • 4. Re: Support of variable in timerDefinition
                kukeltje

                sorry, I answered in the wrong topic...

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

                  I think it would be great for the pvm to support BPEL or XPATH expressions, but on the short term we could have another property in timerDefinitions to define a variable.
                  When creating the timer, if the variable is a Date object, it would be set and if it is a string, it would be parsed to match a duration or date format.
                  In the PVM extensions, developpers could extend the parsing method to use a different expression than in the PVM.

                  It could be a temporary solution that would allow us to use the PVM timer def in Orchestra.

                  Regards,
                  Pascal

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

                     

                    "kukeltje" wrote:
                    sorry, I <a href="http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161625#4161625">answered in the wrong topic... </a>


                    me too :-)

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

                      i think the best way to support configurable expression languages is to use the script manager that i recently introduced.

                      please check that out. there is some test in the test suite that shows the idea.

                      the timer definition should get an expression property and a language property.

                      then it is up to XPDL and BPEL to configure the right scripting engine (jsr based) in the script manager.

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

                        Hi,

                        I started to look at using expression languages in timers before the migration to maven and it really seemed appropriate.
                        I'm now working on it but scripting engines libraries are missing from the pvm. Could you add them (at least juel or groovy) please?
                        I got the source code of the scripting engines so it's not an immediate issue, but I won't be able to commit until one engine is available in the pvm.

                        Thanks,
                        Pascal

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

                          Can you point heiko to the test that runs if the proper libraries are in the classpath ? I assume that one will be in the exclusion list now.

                          Heiko, could you have a look if those libraries can be added to our own maven repo ?

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

                            The test to run is org.jbpm.pvm.expr.ExpressionTest.java. I updated it and the test runs when I manually launch the test from eclipse.
                            The test uses juel and groovy script engines.

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

                              Hi,
                              I commited a patch to use expressions in TimerDefinition.
                              Supported expressions are durations and expressions representing a date or a duration. The date can be a Date object or a formatted String (the conversion is available by method org.jbpm.pvm.internal.job.TimerImpl.formatDueDate )

                              I provided tests using juel and groovy language, but groovy tests are commented since the libraries are not included in the pvm.

                              Regards,
                              Pascal

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

                                can you explain the patch a bit more ?

                                From the code updates, I can't decipher the problem and the fix that you applied. Especially the change from setDueDateDescription to getDateFromDuration(String expression) in TimerImpl

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

                                  Pascal, 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.

                                  BTW, what is the JobTestTimerSession doing in the main sources ?

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

                                    Pascal, before you introduce such changes, please
                                    1) describe the current situation indicate. that shows that you understand it and gives me the opportunity to quickly know what the change is about
                                    2) describe the problem
                                    3) describe how you want to fix it.
                                    please do this before make bigger commits like the one you did now.

                                    Now I have to try and reverse engineer those 3 things from the code updates. Can you still provide that info ?

                                    1 2 Previous Next