October 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: meeting context

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : - ProcessEngine, Process, ProcessDefinition | - StartEvent (None, Signal, Message) | - Task (None, Send, Receive) | - EndEvent (None, Signal, Message) | - Gateway (Inclusive, Exclusive, Parallel) | - Process, Activity Properties | - Process, Activity Assignments | - Signal, Message | - SequenceFlow | Indeed we need to go over those concepts and establish a common vocabulary. But the complexity of the process constructs does not have to influence the client APIs (and service APIs). The concepts that are exposed in the Activity API do have a direct impact on what kind of process constructs you can build. That exposes e.g. the tree of executions to an activity implementation. "kukeltje" wrote : Basic things I did do with 'the api' are | - start a process | | - end a process | | - signal process to continue (either via default or supplied transition) | | - set a variable | | - read variable | | - get a tasklist | | - end a task | | - get basic properties of a task/node/.... in a process instance (e.g. task.hasEnded()) | | - ... | | This lists indeed the typical basic client API operations. This is the most important interface to get right as this is the first interface that every project using jBPM will be using. And it is unrelated to the complexity of the process constructs. The client API can be developed in the simple-to-complex fashion. Adding new capabilities typically does not influence the previous features that you've build. The event listener API is used in most projects and activity API is only used rarely by our users. But i agree that even for those API's it would be good if we could keep them minimal and stable. For the activity API, the simple-to-complex development strategy does not prevent big changes to the public API. Different forms of concurrency might lead to a different structure of the runtime data. (e.g. changing the tree of executions in a map of activity instances). Such changes have a big impact on the whole activity API and when such a change happens, you'll need to rewrite all the activities. It is in that context that I have been building the PVM over the last two years: shaping the runtime data structure and verifying that all kind of process constructs can be build on top of it. But no matter how long I worked on it and how much of these discussions I already had with the Bull people, I still think it is good to have these concepts reviewed and challenged in the group. The discussions on process constructs should however not take up the full team meeting. Our history shows that out-of-the-box support for the different patterns/constructs has not been a critical success factor. Still I want to improve a on that. (we basically only miss the concurrency pattern that ronald mentions: unstructured forks and joins, which is easy to implement) As mentioned before, apart from the process constructs capabilities, there are the rest of the API concepts like ProcessEngine, Configuration, event/signal/log,and so on. Those things can even more use a good review and debate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181177#4181177 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181177

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM Classloading

by camunda

Hmm, I don't get the problem... 1.) I did run the JUnit tests locally with SUN Java JDK 6 -> no problems! 2.) This exception seems not really related to changes I made (doesn't mean it can not be interrelated): Caused by: java.lang.NullPointerException at org.jbpm.jpdl.par.ResourceAction.execute(ResourceAction.java:24) code is (NPE in second line): | URL resource = getClass().getResource("classresource.txt"); | InputStream stream = resource.openStream(); | Could it have been may run with a state where not everything was committed yet? Or other ideas? What puzzles me really is that I don't get these errors locally, even with Java 6... And they shouldn't have changed class loading basics there either... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181176#4181176 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181176

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: meeting context

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : The API will have core elements and terminology. Each core elements has associated semantics which lead to implementation detail. We want the API to be correct, easy to use and easy to learn. | | The process of finding these core elements (or core concepts) and establishing names for them is important to get one step closer to 'correctness'. | I agree with easy to use and easy to learn. But I also think that correctness is always in the eye of the beholder. Meaning that everyone that is involved with some process engine has a certain background and sees certain use cases it. That background and target use cases determine what is considered as correct. I don't think we'll be able to find BPM concepts that are considered worldwide and generally correct. So we need to make our background as explicit as we can. We need to define our targets and use cases as clear as we can. If we agree on those, then our conclusions and the BPM concepts we consider good should be close enough to have fruitful discussions in the meeting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181171#4181171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181171

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Added serialVersion to VariableContainer

by camunda

There was no serialVersionUid in the class, which is not a good idea I think... I added the serialVersionUid which was automatically generated in the old class (in jbpm 3.2), so jbpm 3.3 serialVersionUid should be compatible with jbpm 3.2 serialVersionUid... So in my eyes it is a correct solution (more correct would have been to add the versionUid at the beginning ;-)) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181167#4181167 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181167

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Default redelivery delay is 500ms

by timfox

The default redelivery delay is currently set to 500ms. This means every cancelled messages by default gets put back as a scheduled delivery (!) I have changed this to zero in my local copy and will be in the next commit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181159#4181159 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181159

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Added serialVersion to VariableContainer

by tom.baeyens＠jboss.com

do you know this is the correct solution ? or is this just a random modification that fixed the problem ? i can't verify as i don't know the details of serial version uids. i only know it is more complicated then most people think it is :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181158#4181158 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181158

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM Classloading

by thomas.diesler＠jboss.com

Hi Bernd, there seems to be a problem with jdk-1.6 related to your changes http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Matrix/24/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181143#4181143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181143

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Some thoughts on large messages and message chunking

by clebert.suconic＠jboss.com

I just created a branch: https://svn.jboss.org/repos/messaging/branches/Branch_Chunk_Clebert I still have some work to do before anyone can take a serious look. I know a few things i want to change. JBM 1.4 took a lot of my attention this week, so I'm a little behind because of that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181134#4181134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181134

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Some comments on new scheduled delivery work

by clebert.suconic＠jboss.com

Can we avoid having a different packet and method for scheduledDeliveryTime? I'm also creating a packet for Big chunks... and the combination of this with ScheduledDeliveryTime would be somewhat weird. Bigchunk & scheduled BigChunk & nonscheduled RegularSize & scheduled RegularSize & nonScheduled If you (Andy) is done with scheduledDelivery, I could take care of the change (if you agree with the change of course). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181133#4181133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181133

16 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Policy Implementation for VFS

by david.lloyd＠jboss.com

It should be... the policy parser won't try to open the URL directly because the actual URL might not be valid (in terms of the classloader) - it might contain a wildcard character for instance. And the security manager won't try to open the class file at check time becase (a) the class is already loaded, (b) it would be a performance nightmare, and (c) it would cause intermittent application failures if it was e.g. an HTTP url. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181106#4181106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181106

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008