[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by david.lloyd＠jboss.com
Ah, namespaced attributes - a great idea, I never even thought of it. However I'm not a big fan of squeezing many data items into a single attribute. I think that for multiple data items we'd still need separate attributes.
But I could totally see something like this (note that I put <gpd:bendpoint> right within - there's no need to add another level of nesting that I can see):
| <process-definition
| xmlns="urn:jbpm.org:jpdl-3.2"
| xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
| name="simple"
| gpd:width="469" gpd:height="439">
| <start-state name="start" gpd:x="150" gpd:y="25" gpd:width="140" gpd:height="40">
| <transition name="to_state" to="first">
| <gpd:bendpoint x="23" y="45"/>
| <gpd:bendpoint x="45" y="67"/>
| <gpd:bendpoint x="22" y="11"/>
| <action name="action" class="com.sample.action.MessageActionHandler">
| <message>Going to the first state!</message>
| </action>
| </transition>
| </start-state>
| <state name="first" gpd:x="150" gpd:y="125" gpd:width="140" gpd:height="40">
| <transition name="to_end" to="end">
| .... and so on ....
|
I don't think separate sections are a good idea. This is XML, I mean we're not talking rocket science here.
In addition, forms.xml could (and should, in my opinion) be merged in - the form declarations can go right with the task node declarations. If it were me I'd even merge in the task forms themselves (they are XHTML after all), though I think that might be pushing the limits of popular acceptance. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043467#4043467
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043467
17 years, 8 months
[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by kukeltje
wfmopen, an engine I looked at before/while choosing jBPM extentds xpdl by using namespaces. They do restrict themselves to functional information like variables, form info (they use xforms), "actionhandlers"
Bendpoints will only be in transitions. They are often not that complex and the additional info will not disturb to much I think(well, hope) and color info should be kept to a real minimum (imo), mayby it should even be in a css file ;-) (just kidding). Personally I would not go for doing things two different ways (so no separate section for e.g. bendpoints. Maybe
| <transition name="to_state" to="first">
| <gpd:edge>
| <gpd:bendpoint x="23" y="45"/>
| <gpd:bendpoint x="34" y="23"/>
| <gpd:bendpoint x="45" y="43"/>
| <gpd:bendpoint x="56" y="26"/>
| <gpd:bendpoint x="23" y="12"/>
| </gpd:edge>
| </transition>
|
could be rewritten as
| <transition name="to_state" to="first" gpd:poly="23,34,11,-22,11,20,11,-17,-33,-14"
| </transition>
|
But that could be totally incompatible with EMF,GEF or whatever eclipse framework is used.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043460#4043460
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043460
17 years, 8 months
[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by camunda
It's difficult to decide that issue I think.
On the one hand, I would be glad to have it one file. We do some XSLT-Transformation on the processes, for example to generate a processs documentation website, using a imagemap on the process. There it is very unhandy to have 2 different files and it would be cool to have only one file.
Also I think is easier to keep everything in sync, if we have it in one file (for example renaming a node without using Eclipse-Plugin: You must also change the node name in the gpd.xml).
But on the other hand, I like the very straightforward process definitions, because I often work directly in the XML. Too much informations about diagram would be really discuting there. I like the example from Koen, with all the bendpoints inside the diagram. That is not nice for modelling the process.
So maybe I will vote for 1 file, with the most important informations (x,y of a node) in the section of the process definition and more "unimportant" additional stuff (like bending points of a transition) in a second section.
One additional question from me: Whats then your oppinion, where to put other additional stuff (user gui form mapping, maybe some additional business variables like cost per task, ...)? Also inside that XML? Or make a own section for everything?
By the way: How is that problem solved in other engines?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043458#4043458
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043458
17 years, 8 months
[Design of JBoss jBPM] - Re: including graphical information in the process definitio
by kukeltje
+1 for everything in one file (except the forms themselves)
Sure it blurs the file to have namespaces, but creating 2 section introduces imo more complexity than it solves. Besides, learning namespaces is easy
Maybe using namespaced attributes like e.g.
| <process-definition
| xmlns="urn:jbpm.org:jpdl-3.2"
| xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
| name="simple" gpd:width="469" gpd:height="439"/>
| <state name="first" gpd:x="150" gpd:y="125" gpd:width="140" gpd:height="40"/>
| <transition name="to_end" to="end">
| <action name="action" class="com.sample.action.MessageActionHandler">
| <message>About to finish!</message>
| </action>
| </transition>
| </state>
| </process-definition>
|
is easier to read
Colors etc are a different thing... should they be included at all or configurable on a higher level e.g. in the gpd, not de pd.
Maybe there it is an option to show/hide the gpd namespaced attributes when editing the source
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043437#4043437
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043437
17 years, 8 months
[Design of JBoss jBPM] - including graphical information in the process definition
by tom.baeyens＠jboss.com
we started an email thread on configurability in the designer of the variable expressions. soon it ended in an interesting ever-returning discussion about wether the graphical information should be included in the process definition. how the link was established between those two will remain in the secrets of history, only to be discovered by IT-archeologists that still have to be born :-)
first david suggested namespaces in the process definition to distinct between different types of information like this:
"david" wrote : Here's an idea - what about having just one XML file and use namespaces
| to disambiguate the different data? This could allow users to add their
| own extensions as well.
|
| Here's a mocked up example, modeled on the "simple" process:
|
| <process-definition
| | xmlns="urn:jbpm.org:jpdl-3.2"
| | xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
| | name="simple">
| | <gpd:diagram width="469" height="439"/>
| | <start-state name="start">
| | <gpd:node x="150" y="25" width="140" height="40"/>
| | <transition name="to_state" to="first">
| | <action name="action" class="com.sample.action.MessageActionHandler">
| | <message>Going to the first state!</message>
| | </action>
| | </transition>
| | </start-state>
| | <state name="first">
| | <gpd:node x="150" y="125" width="140" height="40"/>
| | <transition name="to_end" to="end">
| | <action name="action" class="com.sample.action.MessageActionHandler">
| | <message>About to finish!</message>
| | </action>
| | </transition>
| | </state>
| | <end-state name="end">
| | <gpd:node x="150" y="225" width="140" height="40"/>
| | </end-state>
| | </process-definition>
to which i replied that imo, use of namespaces is not enough known in the developer community. so developers will probably mess up some times and then have to spend time on finding the problem with namespace, which they don't even understand.
then koen replied
anonymous wrote :
| Yes we have been discussing/thinking about this for a long time already.
| There are advantages and disadvantages in both approaches. What about the
| bendpoints for instance? Or the coloring of the node? Do you want to end up
| with xml like:
|
| <process-definition
| | xmlns="urn:jbpm.org:jpdl-3.2"
| | xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
| | name="simple">
| | <gpd:diagram width="469" height="439"/>
| | <start-state name="start">
| | <gpd:node x="150" y="25" width="140" height="40">
| | <gpd:color>
| | <gpd:gradient start="234,124,234" end="232,133,234"/>
| | </gpd:color>
| | </gpd:node>
| | <transition name="to_state" to="first">
| | <gpd:edge>
| | <gpd:bendpoint x="23" y="45"/>
| | <gpd:bendpoint x="34" y="23"/>
| | <gpd:bendpoint x="45" y="43"/>
| | <gpd:bendpoint x="56" y="26"/>
| | <gpd:bendpoint x="23" y="12"/>
| | <gpd:edge>
| | <gpd:annotation>
| | This transition should be reviewed because
| | the bendpoints are badly chosen.
| | </gpd:annotation>
| | <action name="action"
| | class="com.sample.action.MessageActionHandler">
| | <message>Going to the first state!</message>
| | </action>
| | </transition>
| | </start-state>
| | <state name="first">
| | <gpd:node x="150" y="125" width="140" height="40"/>
| | <transition name="to_end" to="end">
| | <action name="action"
| | class="com.sample.action.MessageActionHandler">
| | <message>About to finish!</message>
| | </action>
| | </transition>
| | </state>
| | <end-state name="end">
| | <gpd:node x="150" y="225" width="140" height="40"/>
| | </end-state>
| | </process-definition>
| |
| I have only modified the start state, but I think you can see my point.
|
| We should probably be (re-)discussing this on the forum btw...
to which i now reply: good idea square. both on the suggestion for putting the discussion on the forum as well as mixing graphical information with the process.
Agreed, the graphical information confuscates the structure of the process a bit. But the alternative is that this information is managed in 2 distinct files. In that case, users start making directories per process and they can still can mess up by loosing one of the two files when moving things around. Also, if the developer starts to mess in one file, how will the tooling get the other file back in sync ?
Same situation is there for the links between tasks and forms.
I think 1 file is best. I'm just in doubt wether it is more interesting to have 2 sections, separating the graph structure from the graphical information. or wether the graphical information should be really embedded in the graph structure itself.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043424#4043424
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043424
17 years, 8 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Performance tests status
by sergeypk
I am able to run performance tests against all four providers (JBoss MQ, JBM, ActiveMQ, QPid). I have used JBoss 4.0.5, ActiveMQ 4.1.1, QPid M1, and Messaging version "whatever I had built at the moment", which is something after 1.2.0. I didn't tune ActiveMQ nor QPid in any significant way. For Messaging and JBoss MQ I used the destinations that are deployed by the messaging-perf build script.
Problems:
JBossMQ can't handle high throughput and dies, leaving itself in a non-operable state so no further tests can be run until it's cleaned up. I clean it up by stopping JBoss, removing data, log, tmp, and work directories from the configuration, and then restarting JBoss.
QPid also fails under high loads (both throughput and just high number of messages sent), eating a lot of memory and consuming 100% CPU for a long time without making any progress. I had it even throw an OOME once.
ActiveMQ locks up if a lot of messages are sent to a queue without anybody consuming them at the same time. The "Measured Send Rate vs. Intended Send Rate Remote" test locks up on ActiveMQ because of this.
Messaging seems to run fine so far but I haven't yet tried all the tests.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043413#4043413
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043413
17 years, 8 months
[Design of JBoss Build System] - Ideas for JBoss Retro
by pgier
I have a couple ideas for changes to JBoss Retro.
First, I'd like to move non ant specific stuff out of the ant.tasks package, so the command line interface part of Weaver would be moved to something like:
org.jboss.retro.cli
And other non-ant stuff would be moved into more appropriate packages.
Next, I'd like to move all runtime stuff into it's own package.
So for example
| org.jboss.lang
| org.jboss.util
|
Would be moved to
| org.jboss.retro.runtime.lang
| org.jboss.retro.runtime.util
|
This way the separation between weaver and runtime is a little easier to see.
Taking this a step further, I was thinking that these might be divided into:
org.jboss.retro.runtime.jdk14
and
org.jboss.retro.runtime.jdk15
This way, in the future, retro could support conversions from JSE 6 to 1.5 and/or 6 to 1.4. A conversion from 6 to 1.5 would only need to use classes from the jdk1.5 runtime.
The last part is going to be more difficult and if it sounds like a bad idea, please let me know. I'd like to modify the current ClassRedirectEditor to be more dynamic. When the Weaver starts up, I would like it to build a map containing all of the classes and methods in the new runtime package (org.jboss.retro.runtime.jdk14). Then the modified ClassRedirectEditor will search for all methods matching something in the map. If it exists in the map, then just replace the jdk5 method with the jboss version.
So for example, if the ClassRedirectEditor finds a method like java.lang.Boolean.parseBoolean it will replace the call with the matching method org.jboss.retro.runtime.jdk14.Boolean.parseBoolean.
My plan is to start working on these changes after the SVN conversion, so that the folder changes are tracked.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043312#4043312
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043312
17 years, 8 months