[jBPM] - find User tasks
by Jaber C. Mourad
Jaber C. Mourad [http://community.jboss.org/people/newbeewan] created the discussion
"find User tasks"
To view the discussion, visit: http://community.jboss.org/message/541264#541264
--------------------------------------------------------------
Hi,
I'm trying to find some tasks assign to a user, but no success !
I have done a mock identity service to produce test data
My test process :
My test :
RepositoryService repositoryService = processEngine.getRepositoryService();ProcessDefinition testProcess = repositoryService.createProcessDefinitionQuery() .processDefinitionKey("test").uniqueResult();ExecutionService executionService = processEngine.getExecutionService();ProcessInstance instance = executionService.startProcessInstanceByKey("test");logger.info("instance state : {}", instance.getState());Set activities = instance.findActiveActivityNames();for (String activity : activities) { logger.info("Activity : {}", activity);}
TaskService taskService = processEngine.getTaskService();
tasks = taskService.findPersonalTasks("john");assertFalse("No tasks for John !", tasks.isEmpty());
No tasks for john !
Expected 1 because of the candidate-users="john" am I wrong ?
How to make it works ?
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541264#541264]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM Development] - JBPM-2537
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/541263#541263
--------------------------------------------------------------
Hi,
here comes my comments:
> HuiSheng Xu wrote:
> We should add more information in here. And the state constaints is defined in Task interface. So should we move STATE_TIMEOUT and STATE_CANCELLED from HistoryTask to Task?
>
> Actually, the STATE_COMPLETED field in Task is duplicated by STATE_COMPLETED field in HistoryTask.
>
>
In my opinion Task and HistoryTask are two different entities and they should be kept separated.
States are defined in both places because they are used by different queries. So I think they should be as is.
> HuiSheng Xu wrote:
> 1.Should we modify TaskImpl.isComplete(), let this method fit additional states: 'timeout' and 'cancelled'.
>
> Now the isComplete() is like this:
> *public* *boolean* isCompleted() {
> *if* (Task.STATE_COMPLETED.equals(state)) {
> *return* *true*;
> }
> *if* ((Task.STATE_OPEN.equals(state)) || (Task.STATE_SUSPENDED.equals(state))) {
> *return* *false*;
> }
> *return* *true*;
> }
>
I think this is only internal method and IMO it is about verifying if that was already completed in regular way. Timeout and cancel are not completion states, they just close the task and not complete it. That's why states for them are only for history purposes.
> HuiSheng Xu wrote:
>
> 2. The content of TaskTimeout.java and TaskCancel.java is exactly the same. The only difference of them is the completion state, so should we make a abstract class, e.g. AbstractTaskCancel, and let them inherit the superclass?
>
Yeap, you are right here, they are quite the same. We could make an abstract class or shall we give it some thought and check if they should be the same?!
> HuiSheng Xu wrote:
>
> 3. I notice that there is a jbpm.task.lifecycle.xml configution file in the classpath since jBPM-4.0.0-Alpha2, and it contains the prossible states of task. Should we modify it as well? or this configuration file is useless and should be removed in the future version? The content of this file like below:
> <task-lifecycle initial="open">
> <state name="open">
> <transition name="complete" to="completed" />
> <transition name="suspend" to="suspended" />
> <transition name="cancel" to="cancelled" />
> </state>
> <state name="suspended">
> <transition name="resume" to="open" />
> <transition name="cancel" to="cancelled" />
> </state>
> <state name="cancelled" />
> <state name="completed" />
> </task-lifecycle>
>
I haven't seen it before, so thanks for pointing it out. I did look for it in the code but with the same result as Michael, no real references of it. They should not be used by custom code either since they are internal classes.
Thanks for your comments
Maciej
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541263#541263]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services Development] - CXF jms integration
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541260#541260
--------------------------------------------------------------
1)
AFAIK jbossws-cxf.xml is generated only in case there isn't one provided.
The scenario of deploying both JMS and Servlet endpoints in one war
using one jbossws-cxf.xml DD should be supported.
I don't expect any real issues with this scenario.
2) & 3)
> Jim Ma wrote:
> > If you look at my cxf integration work two weeks ago, you can find what I did except the jbossws-endpoints are mainly follow this suggested approach. But after I realized the jms endpoints needs the jms queue/topic deployment dependencies, I created the BeanMataData and deliever the KernalDeploymentDeployer to deploy the jms endpoints . At present , we can not resolve the deployment dependency in the DA.
True, you cannot resolve dependency on JMS deployers in DA code. This can be done only in deployers.
But you're able to detect if particular DA is JMS DA or Servlet DA. See my suggestion (the pseudocode)
in my previous post how to resolve this issue in our WSDeploymentAspectDeployer constructor.
IOW *you shouldn't introduce additional deployers in AS IL*. You should *do everything in DAs*
and just *leverage the AS IL integration code*.
This said I suggest you to delete both BeaMetaData and KernalDeploymentDeployer in our SPI
and rewrite your solution to follow my suggestions ;)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541260#541260]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [jBPM Development] - JBPM-2537
by Michael Wohlfart
Michael Wohlfart [http://community.jboss.org/people/mwohlf] replied to the discussion
"JBPM-2537"
To view the discussion, visit: http://community.jboss.org/message/541258#541258
--------------------------------------------------------------
Hi Guys,
I also stumbled across the jbpm.task.lifecycle.xml file and tried to find out what it was doing, this is what i managed to figure out so far:
The content of the file is read in org.jbpm.pvm.internal.task.LifeCycle.java, it is parsed and seems to implement a kind of min-process / state machine for the task status. You can call LifeCycle.fireLifeCycleEvent(String eventName, TaskImpl task)and it changes the state of the task according to the transitions defined in jbpm.task.lifecycle.xml.
protected static void fireLifeCycleEvent(String eventName, TaskImpl task) {
// reading the state machine
ExecutionImpl lifeCycleExecution = new ExecutionImpl();
ProcessDefinitionImpl lifeCycleProcess = getLifeCycle(task);
lifeCycleExecution.setProcessDefinition(lifeCycleProcess);
// setting up the current state:
String state = task.getState();
Activity activity = lifeCycleProcess.getActivity(state);
lifeCycleExecution.setActivity((ActivityImpl) activity);
// performing a transition
lifeCycleExecution.signal(eventName);
// transfering the new state to the task
task.setState(lifeCycleExecution.getActivity().getName());
}
I think this is great stuff, unfortunatly I couldn't find any place in the code where LifeCycle.fireLifeCycleEvent(String eventName, TaskImpl task)is called, but to me it seems a nice idea to have the task status and transitions configurable in a single file like this.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541258#541258]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services Development] - CXF jms integration
by Jim Ma
Jim Ma [http://community.jboss.org/people/jim.ma] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/541238#541238
--------------------------------------------------------------
Thanks Alessio and Richard's comments again . Let me summarize our discussion points first , then I will give the issues I can see from my previous experimental work on cxf/jms integration in past two weeks, then you and Richard can continue to add your thoughts and comments:
> 1) Use jbossws-cxf.xml (cxf style configuration file) not the new introduced jbossws-endpoints.xml .
>
Looks like my previous 4 reasons are not the problems at all . To simplify the things , we can use jbossws-cxf.xml to deploy jms transport web service. I agreed for this direction.The one problem I can see if we use jbossws-cxf.xml to deploy jms endpoint so far : jbossws-cxf.xml is now used to customize the default generated cxf deployment descriptor by http endpoint , it will be mixed up with jms endpoint when user specifies the jbossws-cxf.xml for http endpoint ,and also want to deploy the jms endpoint with the same jbossws-cxf.xml. Let's take a example :
////////////////<web.xml>//////////////////
<servlet>
<servlet-name>HelloService</servlet-name>
<servlet-class>org.jboss.test.ws.jaxws.samples.HelloImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloService</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
/////////////////<jbossws-cxf.xml>//////////////////////
<jaxws:endpoint id='HttpHelloService'
implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
</jaxws:endpoint>
<!--jms endpoint->
<jaxws:endpoint id='JMSHelloService'
wsdlLocation="./wsdl/jms-samples.wsdl"
implementor='org.jboss.test.ws.jaxws.samples.HelloImpl>
</jaxws:endpoint>
We name the configuration file to only deploy jms endpoint to something like jbossws-cxf-jms.xml ? or we do not support deploy the jms endpoint and http endpoin in one deployment archive ?
> 2) the approach Richard suggested to do jms integration :
> * extend our UMDM (located in SPI) to provide JMS endpoint abstractions
> * extend our DA framework to distinguish DA aspects intended to create web based endpoints and jms based endpoints
> * update our ASIL (concretely WSDeploymentAspectDeployer) to distinguish between Web DAs and JMS DAs
> * implement CXF DA that will map jboss-cxf.xml MD to our UMDM (ensures CXF -> SPI dependency)
> * implement ASIL DA that will create JMS MD from our UMDM (ensures ASIL -> SPI dependency)
> * implement CXF DA that will register plain JMS endpoints with CXF (ensures CXF -> SPI dependency)
>
If you look at my cxf integration work two weeks ago, you can find what I did except the jbossws-endpoints are mainly follow this suggested approach. But after I realized the jms endpoints needs the jms queue/topic deployment dependencies, I created the BeanMataData and deliever the KernalDeploymentDeployer to deploy the jms endpoints . At present , we can not resolve the deployment dependency in the DA.
Add also distinguish the http endpoint and jms endpoint in jbossws-cxf.xml is difficult, for some configuration file (like the example in 1) you need to parse the wsdl , then you can figour out.
> 3) The Endpoint and ASIL dispatch
> * Endpoint
> - ServletEndpoint -> url address
> - JMSEndpoint -> jms address
> * DA
> - ServletDA
> - JMSDA
OK. You convinced me to create JMSEndpoint for jms transport endpoint . It's ideal to use ServletDA to deploy the ServletEndpoint and JMSDA to handle jms endpoint. But again, DA can not handle the dependency deployment which is required by jms transport endpoints deployment in CXF. Do you have some ideas to change the DA api and eable the dependency in DA ?
>
> 4) jms endpoint from wsdl (soap over jms support) sample
I've created a test case for this : https://svn.jboss.org/repos/jbossws/stack/cxf/branches/jms-integration/mo... https://svn.jboss.org/repos/jbossws/stack/cxf/branches/jms-integration/mo...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/541238#541238]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years