-
1. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 23, 2006 6:35 AM (in response to kukeltje)it is indeed true that some efforts for patterns are only supported in xml parsing. up until now, this didn't give any problems because the patterns-only node constructs were not documented and hence nobody knew about the existence.
i didn't yet remove them completely because i aimed at showing that with jbpm, we can handle any pattern. if it doesn't yet exist, we can simply implement it. the only thing that we have to take care of is that the runtime data structures support all the patterns.
looking at the future, i think that we want to show that the process virtual machine (rebranding of graph oriented programming) is a runtime data structure that can support all patterns. we can develop a separate language for showing this. which isolates our patterns efforts from the jPDL language.
wether we should rip out the patterns nodes from the xml parsing, i don't know. i am not against it, as long as this isn't interpreted as: we give up on patterns.
script in fork is not persisted in the 3.1.x because this breaks db compatibility. you can make it work in your installation by adding the many-to-one in the fork for the script field. this is what has been fixed in HEAD of cvs for 3.2.x releases.
generic mechanism of conditions on transitions is certainly something that i anticipate for 4.0. as at would result in a big effort of explaining these changes in the 3.x releases. -
2. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 23, 2006 8:19 AM (in response to kukeltje)I'll comment on the patterns things later, and (to my ashame) I have to admit that I forgot to mention my jBPM version (happens when you drink to much Jupiler). It is 3.2 from cvs-head. The logging says it is not persisted. I'll check if it is or not.
-
3. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 23, 2006 8:27 AM (in response to kukeltje)everything that is not documented is not persisted.
if you see a violation against that statement, then that should not be the case. -
4. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 23, 2006 5:18 PM (in response to kukeltje)The script on the fork is not persisted, but it is not mentioned anywhere that it should be. What I did find out is that there is a lot of difference between the docs, schema (which in itself is very inconsistent) and behaviour/api of the core. I would like to make a suggestion to get this in line before 4.0 or even better 3.3. Shall I file a jira issue for this?
-
5. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 23, 2006 6:24 PM (in response to kukeltje)would it be to difficult to persist the script on a fork. Since http://jira.jboss.com/jira/browse/JBPM-308 is deferred to 3.2 (according to the log there) can we decide now? What is the alternative? imo it is a nice pattern that can be easily configurable with either a script or an action that calls a JBoss Rules file...
Ronald -
6. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 25, 2006 7:11 AM (in response to kukeltje)Persisting it seems as simple as implementing Fork::read() as
public void read(Element forkElement, JpdlXmlReader jpdlReader) { action = jpdlReader.readSingleAction(forkElement); script = (Script) action; log.debug("read()" + script.getName()); }
If the fork is loaded the action is read back but as an action, not as a script, so casting it fails. This probably needs a small change in the fork.hbm.xml but I have no expertise in that. HEEEEEEEELLLLLPPPPPP ;-) -
7. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 25, 2006 8:58 AM (in response to kukeltje)i think you need to add something like
<many-to-one name="script" column="SCRIPT_" foreign-key="FK_NODE_SCRIPT" />
to the Fork.hbm.xml
this will only be part of 3.2 because we don't want to change the db schema in micro release updates (e.g. from 3.1.2 to 3.1.3)
let me know if this doesn't help. don't forget to regenerate the DDL from the mappings -
8. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 25, 2006 8:59 AM (in response to kukeltje)that many to one needs a cascade="all", but i don't know by heart if that is also the default.
-
9. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 25, 2006 11:22 AM (in response to kukeltje)will be part of 3.2 but isn't yet... correct? I do not intend to fix this for 3.1 or so. I'll give it a try.
Thanks -
10. Re: status of merge, non persisted script on fork, and n-out
kukeltje Oct 25, 2006 12:56 PM (in response to kukeltje)Great Tom, this works perfectly. Sounds stupid but this 'small' enhancement and the little time it took helped me convince one of my colleagues to start investigating jBPM for a serious project.
Probably the same is needed for making the join configurable as well... correct? With a little beanshell an n-out-of-m join can be created in jdpl for the moment (until it becomes an attribute...., same is true for the 'descriminator')
Next step would be to be able to use drools for this also, at least on the fork..... I'm looking into this now I understand more of the internals of jBPM.
btw, I already expected the fork.hbm.xml should be changed this way, just didn't try since I did not expect it to be this simple. -
11. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 25, 2006 2:51 PM (in response to kukeltje)"kukeltje" wrote:
will be part of 3.2 but isn't yet... correct? I do not intend to fix this for 3.1 or so. I'll give it a try.
that's right. it was not yet fixed in 3.2 (although i thought i already fixed it).
thanks for reminding me :-) it's now fixed on my machine and i will check it in one of the next days -
12. Re: status of merge, non persisted script on fork, and n-out
tom.baeyens Oct 25, 2006 2:55 PM (in response to kukeltje)"kukeltje" wrote:
Probably the same is needed for making the join configurable as well... correct? With a little beanshell an n-out-of-m join can be created in jdpl for the moment (until it becomes an attribute...., same is true for the 'descriminator')
Next step would be to be able to use drools for this also, at least on the fork..... I'm looking into this now I understand more of the internals of jBPM.
making the join configurable is not really my priority. if you want, you can add and maintain it. but i would like to keep the jpdl language stable till 4.0. that's where i want to do a revision of the language constructs. and have all things like n-out-of-m and things like that.
improved drools integration is on the todo list for 3.x. don't know yet how that will look like. feel free to prorotype some ideas. if it is additions without changes to the current jpdl language, i won't have much objections. -
13. Re: status of merge, non persisted script on fork, and n-out
brittm Oct 26, 2006 6:36 PM (in response to kukeltje)Ronald,
I put a solution into the contributions section that addresses pattern 6 and 14. http://wiki.jboss.org/wiki/Wiki.jsp?page=MultiChoiceForkAH While it may be overkill for what your doing, you might be able to get some use out of it. Now that I think about it, I really need to update that--I've added some functionality since I posted it.
-Britt