[sebastian.s]

You seem to have a lack of understanding how jBPM works. The process engine does not deal with the information supplied in the form-attribut at all. It just parses the information, stores it and makes it available. The task-form rendering is done by the BPM console. The console rertrieves this information and shows the matching form. The console knows which form to display because in this use case the file name of the form is supplied in the attribute I was talking of. So in your case it's up to you to use this information by writing your own application.

And yes: using JSPs in the console is not possible. Enabling this does not make much sense to me because even if you could forward the user to a JSP site on the web you don't have access to the process without extra work.

[jiemin]

I don't have to use jsp. I just want to handel the user actions in a user activity, so I need a form to receive the events from user. I can for e.g. use a java class (or methods)  to create a form and implement the events. But how can I attach the java class to the task definition?

[sebastian.s]

Have you tried any of the supplied examples for task-forms? Maybe this helps you understand. When using what-ever kind of form for interacting with the process engine  (to perform tasks) you basically do 2 things: you read and manipulate variables and you complete the task providing an outcome. If you want certain actions to be performed after completion of the task you can use java activities coming afterwards or you can put EventListeners on the transitions leaving the user activity and have them perform actions.

[jiemin]

The task form in example uses the FreeMarker template. This template can not handle the user actions.

I want the user actions to be performed in the task, not after completation of the task.

If a user activity can only display some informations to the user or get the text input form user, this is not a really user actity.

I think a construct for the user activity with handling the user actions is not yet available in jPDL/jBPM.

[kukeltje]

Lots of suggestions have been made and you seem to put them in two categories

The first one is that you seem to see part of them as the complete solution and reject them because in your opinion they do not work. The only correct conclusion is that as a complete sollution they do not work. As a basis for doing some investigation in they are good though. E.g.for how to implement a different forms solution in the console, the freemarker template forms implementation is *great*

The second category is the 'not investigated'. E.g. my suggestion to add eventlisteners to a task node (a *wait*-state!) where you can send events to via the 'fire' method on the execution (yes, which you currently have to cast to ExecutionImpl) has not had any attention from you besides 'how should the form definition look like'.... I could have said: "Yes that looks ok IF you implement your own forms frontend to do something with it". That would probably not helped you a lot. I could have worked out a fullblown example (which I still would like to do if you hire me for €100 per hour for 1 week (40h)) or something in between, for which I do not have the time.

So your conclusion that jBPM does not support handling user actions is not correct. It does not handle useractions in a way you want it to. And it does not handle them directly like e.g. jsf backing beans do. Simply because interactions (e.g. jsf pageflow like things) are very different to business processes. The freemarker forms does not support any kind of pageflow, simple because user very often have their own ui frontend and interact with the jbpm api directly (just like behind the scenes the freemarker forms solution does, hint, hint) or like in so many testcases

Using the jBPM api from any javaclass related to any webframework is not very different to using e.g. jpa from that same java class. So please give the eventlisteners on java tasks a try if you really want to declare those user actions in the java task.

Cheers,

Ronald

[kukeltje]

I'm going to take part of my remark back... Fireing events does not work out of the box. The casting and invoking the fire method is just not enough...

I've implemented a FireEventCmd that does work and added this to the ExecutionService. Will attach this to the Jira issue mentioned above so it will be in 4.4 I hope...