Glad I could help. We too are very new to bpm.
As for the persistence, in our situation we have a very slow process (Months) which is externally moved forward via a custom webapp, so obviously we need to persist the token counter. It seemed most logical to us to persist it in the join at update time to ensure we always had the accurate count but if you are persisting the process elsewhere, I would suspect it would work fine too.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970083#3970083
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970083
Well, doing a printDetails() can be even longer. :-)
Pushing the config elements to various interceptor MBeans is a holy grail of sorts, but is not feasible for all elements (some aren't attached to any interceptor, others are used by >1 interceptor, etc).
Re: operations on the cache via the MBean, I'd have to ask why. At the end of the day the JMX interface is a management interface, not an operational registry like JNDI. But at the end of the day, if people need work with the cache via JMX then so be it.
What about a getter on the JMX interface that returns a Cache object which can then be used? This would only work programmatically and within the same VM, of course, and not via a management console.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970079#3970079
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3970079