[Design of JBoss jBPM] - Re: Behavior when next state in a
by kukeltje
Heiko,
anonymous wrote : The aim of the new console to provide a proper solution for the most common jBPM use cases.
Most common 'end-user' *BPM* usecases were (almost all) supported in the older console as well.
- Start processes
- See personal and group tasklist
- act on task (via generated forms)
- (re-)assign tasks
End-user being one of the actors in a process, not jBPM 'customers' in general
What users requested from the console are things like:
- Can I remove/adapt/change menus
- Can I customize look and feel (sometimes even per process)
- Can I customize forms
- Can I have taskbuttons be displayed or not based on e.g. transition conditions in the task (guarded transitions)
- Can I integrate my own (JSF/seam) backingbeans
- Can I go directly to the next task if it is in the same swimlane
- ... and more
Some of these could be put in the console, but many of these kinds of customizations make it hard to upgrade to e.g. a newer console. If we want to encourage people to do these kinds of changes, it would require a lot more documentation. Besides that, marketing/sales/... can come up with more requirements than we can (should) support in a generic console.
Looking back, the type of 'developers' that wanted to do these kinds of changes, were not the most bright ones or people under a lot of pressure thinking they had a quick win adapting something that is already there. The brighter ones probably were aware of these issues and developed their own UI.
The intention of e.g. jbpm4jsf library would have made it even easier then it already is to create your own webapp. The combination of jbpm4jsf and gravel never took off due to a lack of documentation, promotion and to complex usage. Gravel (ajax?) functionality should have been hidden in jbpm4jsf components. So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.
So my conclusion would be that the target usage of the console would still be:
- RAD (initial demonstration of a process)
- management things.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185935#4185935
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185935
15 years, 6 months
[Design of EJB 3.0] - Re: Bringing in ejb3-cache
by bstansberry＠jboss.com
I've analyzed the SPI differences between the cluster-dev branch and trunk's ejb3-cache:
https://www.jboss.org/community/servlet/JiveServlet/download/9565-24-5989...
Can be summarized as:
1) Some minor stuff we just need to sort. Names, stuff missing in one or other that obviously needs to be there, etc.
2) StatefulObjectFactory.create(..) method -- cluster-dev branch's shared state map idea. I believe a version of the shared state map concept could be implemented easily enough by our existing StatefulCache impls; i.e. there is a path to compatibility.
3) Replace current call pattern of Cache.create() returns StatefulBeanContext with Cache.create() returns "id", followed by call to Cache.get("id") returns StatefulBeanContext. Shouldn't be a big deal.
4) StatefulContainer (or some delegate) implements PassivationManager. This might be a bit tricky because StatefulTreeCache currently calls some extra StatefulContainer methods that aren't in PassivationManager and aren't needed by the cluster-dev impl. So have to think a bit about that.
5) Deal with the cache factory stuff, which is somewhat orthogonal, except for the fact that a Cache has a ref to a StatefulObjectFactory and a PassivationManager, both of which are presumably implemented by the container. So if we inject the cache into the container, the container will have to pass back a ref to whatever implements those interfaces.
Sorry, Andrew, this particular post is somewhat hijacking your thread....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185876#4185876
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185876
15 years, 6 months
[Design of EJB 3.0] - Re: Bringing in ejb3-cache
by bstansberry＠jboss.com
To clarify a bit:
First, ha-server-cache-spi and ha-server-cache-jbc have nothing to do with the ejb3 project. They define an spi for the AS project's use of JBC (e.g. web session replication), not ejb3's.
The implementations in ejb3-cache in trunk are not actually used anywhere. AFAIK, they are prototypes, and were used as the foundation for the work I did in the dev branch. (Andrew, you never said otherwise -- just stating that for clarity.)
The stuff discussed in https://www.jboss.org/community/docs/DOC-9565 is a slightly different version of the ejb3-cache SPI (contained in the "cache" module discussed on the wiki), along with a considerably different impl.
The abstractions in ejb3-cache in trunk that are used anywhere outside of ejb3-cache itself are:
Cache
Identifiable
StatefulObjectFactory
>From our Neuchatel discussions, on my borderline-TODO list for AS 5.0.0.GA was to look at those interfaces and reconcile any differences to the work in the dev branch to make sure we had a clean path forward for moving to the dev branch implementation down the road. Sounds like that needs to move from "borderline-TODO" to "do it now". I'll look at it tonight. No World Series on anyway. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185849#4185849
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185849
15 years, 6 months