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: 1. 2. 3. Actual results: Expected results: Additional info:
Could you please provide the steps to reproduce this issue starting from a clean BPM Suite installation?
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: https://github.com/droolsjbpm/drools/blob/6.1.x/drools-persistence-jpa/src/main/java/org/drools/persistence/jpa/processinstance/JPAWorkItemManager.java#L52 I will work to reproduce and provide more details later.
William, 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.
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. Thankyou
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.