Mauricio, Why don't you think that the module should be a web application? And why do you want to put the code that implements the server, client and async. nature in the *jBPM* project?? Thanks, Marco 10/20/2011 02:09 PM, Mauricio Salatino: Hi marco, We have implemented a project that basically provides the bindings for the current module with the WS Interface proposed by WS-HT standard. Doing that we have introduced a lot of boilerplate with the data types proposed in the standard. If you take a look at the new interface that is called TaskService you will see that thats the synchronous interface with the methods that we can expose with WS or JMS(Commands like in drools), but I don't believe that the module should be a Web application. If you talk with kris about this you will find that I have a couple of pending task related with hooking up the task service to the JNDI tree to be able to be used by multiple applications for example in tomcat or jboss. I'm open to create a project in my github account where we can play around and coordinate that effort, I also have access to a jenkings server to keep it blue. The main problem with the module human task module is that is being used and we cannot break it or change it completely. -> https://github.com/Salaboy/human-tasks-playground I've already added you Marco as a collaborator.. I think that the main idea will be to build a proposal to see what we can do and how we can handle the existing users. Marco what do you think about that? what are the main goals that you want to achieve? If someone else is interested in this idea please write us back. Cheers On Thu, Oct 20, 2011 at 8:58 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > > Mauricio, > > You know the code better than I do, but IMO, the infrastructure code in > that module is not okay. > > > I really like the idea of having this human task module completely > decoupled from the rest of the project > > I am all for this. Would you mind hosting it on your github, then? > > > A lot of the *jBPM* related code seems to be okay, it's mostly how the > module is set up that bothers me. > > It seems like it would be a better idea to implement the human-task as a > webservice war. That way, we could get rid of the server, client and > asynchronous code in the module and concentrate on the *jBPM* stuff. The > JAX-WS standard includes asynchronous webservices, and webservices can be > coupled to JMS implementations as well. > > For more information on JAX WS asynchronous services, please see the > following links: > > - > http://today.java.net/pub/a/today/2006/09/19/asynchronous-jax-ws-web-serv... > - > http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2F... > - > http://biemond.blogspot.com/2011/02/building-asynchronous-web-service-wit... > - (not especially about async services, but gives you an idea of what > the code looks like) > > > Thanks, > Marco > > 10/20/2011 01:27 PM, Mauricio Salatino: > > Hi Marco, > My opinion about it is good, I mean, we need to improve the transport > layer of it, but the rest of the code is ok. If you take a look at one of my > last pull requests, it was related with the fact that we need a synchronous > interface to simplify all the interactions and to hide all the boilerplate > of async communications. > > If you want to simply things to start having more smaller and controlled > pieces I suggest you to take a look at this other pull request: > https://github.com/droolsjbpm/jbpm/pull/28 > Which aims to split the logic that we currently have inside the human task > module into several modules with their own dependencies. That will allow us > to do internal changes, api changes as well as transport changes in a more > manageable way. > > I really like the idea of having this human task module completely > decoupled from the rest of the project and I'm willing to help as much as I > can to improve it because I found that not only jBPM can leverage the power > of it. > > Let's keep this discussion open so we can gather more requirements from > the people that is using it. > > Cheers > > On Thu, Oct 20, 2011 at 7:19 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > >> 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 >> >> > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jugargentina.org > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > > > -- > jBPM/Drools developer > Utrecht, the Netherlands > > -- - CTO @ http://www.plugtree.com - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio - -- jBPM/Drools developer Utrecht, the Netherlands

Mauricio, I have absolutely no problem with first packaging the human-task project in a jar, and then *also* having it packaged as a web application/web service -- just like Brad described. I agree with your point about architecture: if you can offer the human-task as a jar, that makes it's inclusion into other systems/applications much easier. And it would be very cool to have it become a WS-HT library that is widely used. I'll write you/the list probably next week with a suggestion for how we could achieve this: otherwise, feel free to submit a "road-map" yourself! Lastly, with regards to your pull request/split idea: I don't think that the human-task needs to be split. I think we just need to delete the transport part. :) We can then refactor the "jbpm logic" part so that it has a primary interface that the web service or other architectures can interface with. @Brad: thanks for the suggestion about CXF. Those are exactly the lines I was thinking along. Thanks, Marco 10/20/2011 02:21 PM, Mauricio Salatino: A web application will limit to all the users that wants to add the logic of the Human Task Component embedded inside their own application which I think that is a very good use case. For example, one of the things that I'm pushing forward is the fact that you can create tasks from rules instead of creating tasks just from business processes. If you want to do that having all the logic inside a web application will complicate your application architecture. I'm not against of having a web application that wraps the human task component functionality but we should provide also a simple library that can be embedded in any environment. I agree with you on the second question, I mean.. that's why I was trying to decouple the logic from the transport in that pull request that breaks apart the current single module into like 8 sub projects. The other thing that it's important to mention is that I believe that the human task component should go outside of the jBPM project to promote the use from different other projects. I would love to see the human task functionality included in JBoss AS for example as a service, but not as a web application :) Cheers On Thu, Oct 20, 2011 at 9:16 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > Mauricio, > > Why don't you think that the module should be a web application? > > And why do you want to put the code that implements the server, client and > async. nature in the *jBPM* project?? > > Thanks, > Marco > > 10/20/2011 02:09 PM, Mauricio Salatino: > > Hi marco, > We have implemented a project that basically provides the bindings for the > current module with the WS Interface proposed by WS-HT standard. Doing that > we have introduced a lot of boilerplate with the data types proposed in the > standard. If you take a look at the new interface that is called TaskService > you will see that thats the synchronous interface with the methods that we > can expose with WS or JMS(Commands like in drools), but I don't believe that > the module should be a Web application. If you talk with kris about this you > will find that I have a couple of pending task related with hooking up the > task service to the JNDI tree to be able to be used by multiple applications > for example in tomcat or jboss. > > I'm open to create a project in my github account where we can play > around and coordinate that effort, I also have access to a jenkings server > to keep it blue. The main problem with the module human task module is that > is being used and we cannot break it or change it completely. > > -> https://github.com/Salaboy/human-tasks-playground > > I've already added you Marco as a collaborator.. > I think that the main idea will be to build a proposal to see what we can > do and how we can handle the existing users. > Marco what do you think about that? what are the main goals that you want > to achieve? > If someone else is interested in this idea please write us back. > > Cheers > > On Thu, Oct 20, 2011 at 8:58 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > >> >> Mauricio, >> >> You know the code better than I do, but IMO, the infrastructure code in >> that module is not okay. >> >> > I really like the idea of having this human task module completely >> decoupled from the rest of the project >> >> I am all for this. Would you mind hosting it on your github, then? >> >> >> A lot of the *jBPM* related code seems to be okay, it's mostly how the >> module is set up that bothers me. >> >> It seems like it would be a better idea to implement the human-task as a >> webservice war. That way, we could get rid of the server, client and >> asynchronous code in the module and concentrate on the *jBPM* stuff. The >> JAX-WS standard includes asynchronous webservices, and webservices can be >> coupled to JMS implementations as well. >> >> For more information on JAX WS asynchronous services, please see the >> following links: >> >> - >> http://today.java.net/pub/a/today/2006/09/19/asynchronous-jax-ws-web-serv... >> - >> http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2F... >> - >> http://biemond.blogspot.com/2011/02/building-asynchronous-web-service-wit... >> - (not especially about async services, but gives you an idea of >> what the code looks like) >> >> >> Thanks, >> Marco >> >> 10/20/2011 01:27 PM, Mauricio Salatino: >> >> Hi Marco, >> My opinion about it is good, I mean, we need to improve the transport >> layer of it, but the rest of the code is ok. If you take a look at one of my >> last pull requests, it was related with the fact that we need a synchronous >> interface to simplify all the interactions and to hide all the boilerplate >> of async communications. >> >> If you want to simply things to start having more smaller and >> controlled pieces I suggest you to take a look at this other pull request: >> https://github.com/droolsjbpm/jbpm/pull/28 >> Which aims to split the logic that we currently have inside the human >> task module into several modules with their own dependencies. That will >> allow us to do internal changes, api changes as well as transport changes in >> a more manageable way. >> >> I really like the idea of having this human task module completely >> decoupled from the rest of the project and I'm willing to help as much as I >> can to improve it because I found that not only jBPM can leverage the power >> of it. >> >> Let's keep this discussion open so we can gather more requirements from >> the people that is using it. >> >> Cheers >> >> On Thu, Oct 20, 2011 at 7:19 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: >> >>> 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 >>> >>> >>>

Sure, I can help with packaging the java interface as a cxf war file. That should be fairly trivial once the straight java interface is complete. Shoot me a message with the interface and I will package it. Would providing a cxf war with web services and soap over jms as an example help? Brad On Oct 20, 2011, at 9:04 AM, "Mauricio Salatino" <salaboy(a)gmail.com&gt; wrote: Hehe.. I agree with you.. but we can't just delete it.. that's why splitting them we can have the core and then add more transport to it. CXF is fine and we are also using that along with the WS-HT spec interface to expose the module and it works fine.. it just add a lot of boilerplate. I think that we can play a little bit with the core and start providing different interfaces. I really appreciate kris input on this... because I think that he can give us a good vision about what things we should include and what things we can left out. My personal roadmap will be: 1) get the core and remove all the unneeded transport layers 2) review the APIs, there are a lot of things missing there and we can decouple the APIs better (users, queries, taskLists, etc) 3) forget about the transport and just get a simple jar with all the functionality. 4) get a detailed plan for integrations (transactions, db configurations, etc) Most of these things are just copying what is there and break backward compatibility, and if we do that we need to be sure that we will have a synchronization point in the future.. Brad, do you want to help us? what's your github account? Cheers On Thu, Oct 20, 2011 at 9:47 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > Mauricio, > > I have absolutely no problem with first packaging the human-task project > in a jar, and then *also* having it packaged as a web application/web > service -- just like Brad described. > > I agree with your point about architecture: if you can offer the > human-task as a jar, that makes it's inclusion into other > systems/applications much easier. And it would be very cool to have it > become a WS-HT library that is widely used. > > I'll write you/the list probably next week with a suggestion for how we > could achieve this: otherwise, feel free to submit a "road-map" yourself! > > Lastly, with regards to your pull request/split idea: I don't think that > the human-task needs to be split. I think we just need to delete the > transport part. :) We can then refactor the "jbpm logic" part so that it > has a primary interface that the web service or other architectures can > interface with. > > > @Brad: thanks for the suggestion about CXF. Those are exactly the lines I > was thinking along. > > Thanks, > Marco > > > 10/20/2011 02:21 PM, Mauricio Salatino: > > A web application will limit to all the users that wants to add the logic > of the Human Task Component embedded inside their own application which I > think that is a very good use case. For example, one of the things that I'm > pushing forward is the fact that you can create tasks from rules instead of > creating tasks just from business processes. If you want to do that having > all the logic inside a web application will complicate your application > architecture. I'm not against of having a web application that wraps the > human task component functionality but we should provide also a simple > library that can be embedded in any environment. > > I agree with you on the second question, I mean.. that's why I was > trying to decouple the logic from the transport in that pull request that > breaks apart the current single module into like 8 sub projects. The other > thing that it's important to mention is that I believe that the human task > component should go outside of the jBPM project to promote the use from > different other projects. I would love to see the human task functionality > included in JBoss AS for example as a service, but not as a web application > :) > > Cheers > > On Thu, Oct 20, 2011 at 9:16 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: > >> Mauricio, >> >> Why don't you think that the module should be a web application? >> >> And why do you want to put the code that implements the server, client >> and async. nature in the *jBPM* project?? >> >> Thanks, >> Marco >> >> 10/20/2011 02:09 PM, Mauricio Salatino: >> >> Hi marco, >> We have implemented a project that basically provides the bindings for >> the current module with the WS Interface proposed by WS-HT standard. Doing >> that we have introduced a lot of boilerplate with the data types proposed in >> the standard. If you take a look at the new interface that is called >> TaskService you will see that thats the synchronous interface with the >> methods that we can expose with WS or JMS(Commands like in drools), but I >> don't believe that the module should be a Web application. If you talk with >> kris about this you will find that I have a couple of pending task related >> with hooking up the task service to the JNDI tree to be able to be used by >> multiple applications for example in tomcat or jboss. >> >> I'm open to create a project in my github account where we can play >> around and coordinate that effort, I also have access to a jenkings server >> to keep it blue. The main problem with the module human task module is that >> is being used and we cannot break it or change it completely. >> >> -> https://github.com/Salaboy/human-tasks-playground >> >> I've already added you Marco as a collaborator.. >> I think that the main idea will be to build a proposal to see what we can >> do and how we can handle the existing users. >> Marco what do you think about that? what are the main goals that you want >> to achieve? >> If someone else is interested in this idea please write us back. >> >> Cheers >> >> On Thu, Oct 20, 2011 at 8:58 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: >> >>> >>> Mauricio, >>> >>> You know the code better than I do, but IMO, the infrastructure code in >>> that module is not okay. >>> >>> > I really like the idea of having this human task module completely >>> decoupled from the rest of the project >>> >>> I am all for this. Would you mind hosting it on your github, then? >>> >>> >>> A lot of the *jBPM* related code seems to be okay, it's mostly how the >>> module is set up that bothers me. >>> >>> It seems like it would be a better idea to implement the human-task as a >>> webservice war. That way, we could get rid of the server, client and >>> asynchronous code in the module and concentrate on the *jBPM* stuff. >>> The JAX-WS standard includes asynchronous webservices, and webservices can >>> be coupled to JMS implementations as well. >>> >>> For more information on JAX WS asynchronous services, please see the >>> following links: >>> >>> - >>> http://today.java.net/pub/a/today/2006/09/19/asynchronous-jax-ws-web-serv... >>> - >>> http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2F... >>> - >>> http://biemond.blogspot.com/2011/02/building-asynchronous-web-service-wit... >>> - (not especially about async services, but gives you an idea of >>> what the code looks like) >>> >>> >>> Thanks, >>> Marco >>> >>> 10/20/2011 01:27 PM, Mauricio Salatino: >>> >>> Hi Marco, >>> My opinion about it is good, I mean, we need to improve the transport >>> layer of it, but the rest of the code is ok. If you take a look at one of my >>> last pull requests, it was related with the fact that we need a synchronous >>> interface to simplify all the interactions and to hide all the boilerplate >>> of async communications. >>> >>> If you want to simply things to start having more smaller and >>> controlled pieces I suggest you to take a look at this other pull request: >>> https://github.com/droolsjbpm/jbpm/pull/28 >>> Which aims to split the logic that we currently have inside the human >>> task module into several modules with their own dependencies. That will >>> allow us to do internal changes, api changes as well as transport changes in >>> a more manageable way. >>> >>> I really like the idea of having this human task module completely >>> decoupled from the rest of the project and I'm willing to help as much as I >>> can to improve it because I found that not only jBPM can leverage the power >>> of it. >>> >>> Let's keep this discussion open so we can gather more requirements >>> from the people that is using it. >>> >>> Cheers >>> >>> On Thu, Oct 20, 2011 at 7:19 AM, Marco Rietveld <mrietvel(a)redhat.com&gt;wrote: >>> >>>> 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 >>>> >>>> >>>> > -- - CTO @ http://www.plugtree.com - MyJourney @ http://salaboy.wordpress.com - Co-Founder @ http://www.jugargentina.org - Co-Founder @ http://www.jbug.com.ar - Salatino "Salaboy" Mauricio - <ATT00001.c>

** (Took me a while to find the time to look at this, sorry for the delay) I think you should consider the jbpm-human-task module as a combination of several components (and we're actually trying to split it up a little following this structure): - a simple java component, based on the concepts in the WS-HT spec. that allows you to manage the life cycle of tasks (we've now introduced a simple API that this service exposes) - tests for the functionality of that component - communication/transportation code that exposes this service to remote clients (e.g. using Mina or HornetQ) Having the component as a simple component (and not always as a web service for example) is necessary, as you can then just embed it as part of your application and use local communication rather than WS invocations (which might be important for performance. We're actually probably going to deploy the task service locally next to the jBPM engine in the jbpm-console for the next service. I definitely agree that jBPM is not a server project or anything related to that, it is a BPM project. So a Java component that manages the life cycle of tasks makes sense in this context. Developing our own client-server communication mechanism doesn't. But we do want to make sure that this service can actually be used of course. To do that, we need to make it accessible remotely. So, from my point of view, our goal is to use existing technologies in combination with our task service component so we can expose it remotely. That means not reinventing the wheel but reusing existing technologies that exist in this area and applying them / configuring them to our use case. The tests in the human task service project are indeed starting to annoy me as well. No matter what the reason is, we should solve them (and yes, I mean "we", not "you" ;)). Let's try to find some time to discuss on irc what we need to improve to solve these issues. Let's focus on the HornetQ impl. first (as that's the one we recommend for use in production). We should just be able to set up / configure HornetQ so it can be used to send messages from client to server. I also support the idea of being able to just run this as a simple war, there's even a prototype impl. that already does that, but even then there's still the question of what communication mechanism to use. Currently the human task service is part of the jbpm project, although I agree that it could be used in a broader context as well, but I think it makes sense to keep it there until we see more pressing reasons to create a separate project for it. Kris On 10/20/2011 12:19 PM, Marco Rietveld wrote: 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 listjbpm-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbpm-dev _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev