Re: [jbpm-dev] Human-Task module problematic..

Hi guys, Having looked through the architecture of the Human-Task module in the last month or so, I've become fairly pessimistic about it. The biggest problem I'm seeing is that the "wheel is reinvented" a couple times -- and the "reinvented wheels" that are present in the Human-Task service will be a pain to maintain/troubleshoot. The "reinvented wheels" are things like the following: 1. The server logic 1. BaseJMSTaskServer, TaskServerHandler, etc. 2. The client logic 1. TaskClientHandler, the ResponseHandler and all it's children classes) 3. The asynchronous/concurrency logic 1. AbstractBlockingResponseHandler{.waitTillDone(long) } and every class that uses that method (and every class that uses the class that uses that method.. etc.) I think my frustration with this can best be expressed by the fact that jBPM is a process engine project -- it's not a server project, it's not a (service) client project, and it certainly isn't a project that supports asynchronous communication. And yet, we're implementing all 3 in the module. :/ ** Lastly, the human-task module code is the reason that the jbpm builds (on hudson.jboss.org) have been failing for the last month or so. And the tests are *not* failing because the *tests* are wrong: the tests are failing because there's a race condition in the code, and it occurs when you run the human-task code on a 1. heavily loaded server that's experiencing 2. lots of network traffic. Which is what the hudson.jboss.org is. I guess I'm wondering what other people's opinions about this are! Thanks, Marco -- jBPM/Drools developer Utrecht, the Netherlands _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev