Bug 1272209 - WorkItemHandler mix references
WorkItemHandler mix references
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Maciej Swiderski
Radovan Synek
Depends On:
  Show dependency treegraph
Reported: 2015-10-15 14:56 EDT by Victor Cornejo
Modified: 2015-11-27 10:42 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-09 07:44:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Victor Cornejo 2015-10-15 14:56:09 EDT
Description of problem:
We have two version of my projects in production, but apparently it is a conflict between them at use WIH to call external web services.

If you look at detail the trace.. we are using version 1.1 from repository, however below in trace detail indicate that are using jar -1.0-SNAPSHOT.jar (it belogs to version 1.0 pf the project.

Error Trace.
09:40:33,611 INFO  [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (jBPMClusteredScheduler_Worker-4) Creating Service {http://esb.bci.cl/productos/colocaciones/solicitudes/AprobacionComercial}AprobacionComercialService from WSDL: jar:file:/root/.m2/repository/cl/bci/chip/bci-chip-aprobacioncomercialsuc-wsclient/1.1/bci-chip-aprobacioncomercialsuc-wsclient-1.1.jar!/AprobacionComercialSUC.wsdl
09:40:33,640 SEVERE [cl.bci.bpm.suc.workitem.ObtenerEstadoSUCWorkItemHandler] (jBPMClusteredScheduler_Worker-4) ERROR WS Servicio obtencion de JOF.: javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Service class cl.bci.esb.productos.colocaciones.solicitudes.aprobacioncomercial.AprobacionComercialPortType does not implement the inyectarSolicitud method.
        at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:338) [cxf-rt-frontend-jaxws-2.6.8.redhat-7.jar:2.6.8.redhat-7]
        at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:323) [cxf-rt-frontend-jaxws-2.6.8.redhat-7.jar:2.6.8.redhat-7]
        at javax.xml.ws.Service.getPort(Service.java:99) [jboss-jaxws-api_2.2_spec-2.0.1.Final-redhat-2.jar:2.0.1.Final-redhat-2]
        at cl.bci.esb.productos.colocaciones.solicitudes.aprobacioncomercial.AprobacionComercialService.getAprobacionComercialPort(AprobacionComercialService.java:56) [bci-chip-aprobacioncomercialsolcred-wsclient-1.0-SNAPSHOT.jar:]
        at cl.bci.bpm.suc.workitem.SUCWorkItemHandler.obtenerServicio(SUCWorkItemHandler.java:29) [bci-chip-aprobacioncomercialsuc-wsclient-1.0-SNAPSHOT.jar:]
        at cl.bci.bpm.suc.workitem.ObtenerEstadoSUCWorkItemHandler.executeWorkItem(ObtenerEstadoSUCWorkItemHandler.java:95) [bci-chip-aprobacioncomercialsuc-wsclient-1.0-SNAPSHOT.jar:]
        at org.drools.persistence.jpa.processinstance.JPAWorkItemManager.internalExecuteWorkItem(JPAWorkItemManager.java:56) [drools-persistence-jpa-6.0.3-redhat-9.jar:6.0.3-redhat-9]

Version-Release number of selected component (if applicable):
BPMS 6.0.3

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 2 William Antônio 2015-10-15 15:52:12 EDT
Could you please provide the steps to reproduce this issue starting from a clean BPM Suite installation?
Comment 3 William Antônio 2015-10-15 18:37:30 EDT
Further analysis with Samuel Tauil show that the problem is with the WorkItem persistence, mainly the class JPAWorkItemManager, which stores the WIH in a map using the WIH name as the key and sometimes it leads to the wrong WIH version to be loaded:


I will work to reproduce and provide more details later.
Comment 4 Maciej Swiderski 2015-10-23 08:14:21 EDT

analysis described in comment 3 look weird to me as WorkItemManager (regardless of its type - default or jpa) is ksession scoped. That means single ksession will have its own instance of work item manager. So it's technically impossible to have loaded different versions by the same ksession. Moreover ksession is managed by runtime manager and depending of the strategy used they are either created on every request or created only once.

The only situation when this could happen is when you use wrong ksession to deal with process instance. That would mean you use ksession from project version one to proceed with process from version 2. That can only happen when process ids are the same between versions of the project. It won't happen if you follow best practice to always change process id whenever you upgrade project. That way you ensure that even if you use wrong ksession to attempt to proceed with process instance it will fail to load because that ksession does not have process definition for given process instance.
Hope this provides some insight into the internals.
Comment 5 Victor Cornejo 2015-10-23 22:02:38 EDT
Thank You for the explanation.
We only was changed the process version and deployment version.
- I'll change the process id definition and try to reproduce the issue.

Additionally we try to reproduce de bug using wrong remote kiesession.

Comment 6 William Antônio 2015-11-09 07:44:02 EST
I think this is not a bug. I could not reproduce the problem and now that Maciej explained a little more about how WIH works, it seems I will not be able to reproduce it.

Victor, I am closing this. Please continue working on it on the support case unless we have a reproducer to prove this is a bug.

Note You need to log in before you can comment on or make changes to this bug.