JBossDeveloper

Ronald,

Thanks! I'll take a look at the HEAD, this is something I really could use.

"kukeltje" wrote:
also:
- setting timers dynamically based on processvariables
- choosing a specific subprocess runtime instead of designtime (e.g. with one main process and many different subprocesses per customer)

There was a lot of request for them, specifically the first one.

I had to mention these since I implemented and documented them, including unit tests ;-)

"mvaldes" wrote:

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

those use cases are indeed important (and also reported by our users in Bonita :-)

Again......... they are already in jpdl 3.x... and easily migratable to the pvm

agreed. but someone has got to do it. see what can be reused, migrate, set up test,...

i was hoping that miguel's post was more then just a plug :-)

:-)

Sure, we can easily add variables support on timers but I would like to wait until the pvm refactor is finished (as there are some modifications on timers regarding activities intances...)

On the subprocess flag, we could also take a look at that. Currently we have added support for subprocesses at XPDL extension level so i'm not sure whether this can be added at PVM level... is there native support for subprocesses at PVM level ?

regards,
Miguel Valdes

:-)

Sure, we can easily add variables support on timers but I would like to wait until the pvm refactor is finished (as there are some modifications on timers regarding activities intances...)

On the subprocess flag, we could also take a look at that. Currently we have added support for subprocesses at XPDL extension level so i'm not sure whether this can be added at PVM level... is there native support for subprocesses at PVM level ?

regards,
Miguel Valdes

by end of this week, timers, activity instances should be stable

i'll try to add native support for sub processes by that time as well

ok, now I know what you mean...

I've gone though the wsbpel docs, just out of curiosity, and came across some examples of wait-for, wait-until, conditions on several other items and other stuff

The format is :

$monthlyPostDateTime

$timesheetEntriesApproval and $timesheetExpensesApproval
$iterations > 3

$quotes[$n]

'P3DT10H'

bpel:getVariableProperty( "InvoiceStatusResponse","inv:status")
< 9

$shippingRequest.customerInfo

<for expressionLanguage="anyURI"?>duration-expr</for> |
<until expressionLanguage="anyURI"?>deadline-expr</until> )?
<repeatEvery expressionLanguage="anyURI"?>
 duration-expr
</repeatEvery>?

expressionLanguage. This attribute specifies the expression language used in the process. The default value for this attribute is:
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of
XPath 1.0 within WS-BPEL 2.0. The URI of the corresponding XPath 1.0
specification is: http://www.w3.org/TR/1999/REC-xpath-19991116.

and

The value of the queryLanguage and expressionLanguage attributes on the
process element are global defaults and can be overridden on
specific activities like assign using the mechanisms defined later in
this specification. In addition the queryLanguage attribute is also
available for use in defining BPEL property aliases in WSDL. BPEL processors
MUST:
- statically determine which languages are referenced by queryLanguage or expressionLanguage attributes either in the BPEL process definition itself or in any BPEL property definitions in associated WSDLs and
- if any referenced language is unsupported by the BPEL processor then the processor MUST NOT process the submitted BPEL process definition.

So I guess it's very clear on one hand and complicated on the other which at least makes clear that it has to be configurable