December 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Fluent interface on Commands

by thomas.diesler＠jboss.com

It is funny that this thread pop up right now, because over the weekend I investigated whether possible incompatibilities leaked into the jBPM3 code base. The extend of these incompatibilities can be seen running this command in target/classes for both jbpm-3.3.0 and jbpm-3.3.1 | find . -name "*.class" | sort | grep class | sed "s/.class//" | xargs javap -classpath . -protected | The result I put in https://svn.jboss.org/repos/jbpm/jbpm3/trunk/modules/core/src/main/etc/ Obvious incompatibilities are in | BatchSignalCommand | ChangeProcessInstanceVersionCommand | DeleteProcessdefinitionCommand | HibernateHelper | Customer code that accesses API that has changed in this incompatible way would break. Bernd, is it ok for you to roll back these changes until code freeze 20-Dec? If not, please tell me so we can do it. This is a blocking issue for the release. https://jira.jboss.org/jira/browse/JBPM-1919 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196461#4196461 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196461

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Fluent interface on Commands

by kukeltje

anonymous wrote : introducing these kind of changes in 3 might cause unecessary frustration with our current userbase. it being more cool is no reason to break compatibility, i think. | You *think*? LOL... normally you are way more sure about things View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196376#4196376 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196376

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Fluent interface on Commands

by tom.baeyens＠jboss.com

let's keep the fluent interface updates for jbpm 4. you can refactor the commands in jbpm 4 in the next iteration (jan-feb) if you have the time. introducing these kind of changes in 3 might cause unecessary frustration with our current userbase. it being more cool is no reason to break compatibility, i think. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196373#4196373 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196373

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: task component interface comments

by kukeltje

anonymous wrote : I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different? You got a point there... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196369#4196369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196369

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: task component interface comments

by alex.guizar＠jboss.com

Beyond the usual conventions, there are two things I dislike about returning Task from the setters: 1. the "set" prefix prevents a true "fluent" method chain. Compare the method chains with and without the TaskBuilder. 2. what if I want to add comments, subtasks, etc? the task interface does not have methods for that, you have to go back to the task service. The task builder can "remember" the task service that created it and invoke it internally. task = taskService.buildTask() | .name("report expenses") | .due(today) | .subTask() | .name("gather receipts") | .due(beforeLunch) | .subTask() | .name("capture amounts") | .due(beforeLeaving) | .done(); anonymous wrote : TaskBuilder is definitely not good. Task with setter is the way to go. I got the TaskBuilder idea from the ProcessFactory that is already in the PVM module. How are they different? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196329#4196329 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196329

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Fluent interface on Commands

by camunda

Hi. After discussing fluent interfaces in jbpm 4 (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146922) I was quite motivated to introduce them in the Commands as well. And when using them, it is really much cooler and more easy to have the return values of the setters. So I can say, I really like to have them :-) But the problem is, the signature of the existing Commands have changed by it. So I realized, all client libraries using jbpm have to be recompiled. Not changed, but recompiled against the new jbpm-jpdl.jar, right? So this may be a show stopper, or what do you think? I tend to reverse all these changes (even if I will miss them), otherwise migration to new jbpm-jpdl.jar caused to much confusion. Opinions? Thomas, what do you say? Related jira issue: https://jira.jboss.org/jira/browse/JBPM-1905? Thanks Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196293#4196293 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196293

17 years, 4 months

1
0
0 / 0

Re: Migration

by Ronald van Kuijk

JPDL Changes: +90% of the conversion of JPDL would be acceptable for me. In fact I think it will be higher. The number of users that use really complex stuff is limited. The number of users that accidentally abuse some functionality because it was never intended that way but works might be higher. API changes: They are no problem for me since we've isolated those in PAO (Process Access Objects) where the real jbpm api is used in a limited number of places (like it is hidden when you use seam). Not sure about other users though, I just hope they follow best practices as well. Application/process retesting Not a real problem for two reasons. - I would introduce jBPM 4 in combination of a major release of the application so it needs full testing anyway. - I encourage TDD for the processes as well, so the behaviour of jBPM 4 could be tested before the full application is tested and errors caused by upgrading jBPM could be tackled first. DB change: That is the area where I have the least knowledge about and like to keep it that way. Way to many other technologies that I have to keep track of. But I do have some additional remarks. My argument about the direct access to the database via jBPM was not because of schema changes, but because of the initial proposal (because of disgust ;-)) to remove this. That I think is unacceptable. People who have written queries directly to the database are mostly aware of the risk and are knowledgable about creating the queries. They should have encapsulated those as well and so I think we have the 'liberty' to change the schema since they will be able to adapt fairly easily. They will start asking questions like: what will happen with the DB for 4.1 (easy answer: nothing that requires you to change again) or 5 (no idea, Tom?) or .... I think Thomas is right stating that deployment to 3 or 4 could be decided in the new api and be based on the schema. Cannot remember this argument came up in Antwerp btw. It would require code changes for the client since they have to start using 'the' api. Regarding Thomas additional statement: >> Also mixing the libraries will be a very hard or impossible. >Also not true. Project libraries should have distinct maven artefact ids. > The container integration layer takes care of transitive dependencies that are available to all BPM engines. For normal webapps this might be true by using classloader scoping. I've never used JBoss ESB extensively, so not sure if something similar is possible (also not remeber this remark from Antwerp, but better late than never) What you (and Thomas) are in fact stating is that if Toms statement > In most deployment environments, I don't think our users will have an option to run jBPM 4 in a different DB schema then their own app and jbpm 3. Can be addressed/solved/documented in some way, co-existence of 3 and 4 prevails. Just my quick remarks Ronald On Wed, Dec 10, 2008 at 3:31 PM, Burr Sutter <bsutter(a)redhat.com> wrote: > I'm curious to see if Joram, Bernd & Ronald agree (even a little) with my > suggestion that a 90% conversion of DB, JPDL & API and the need to re-test > the end-user application are substantial barriers to the any migration. The > question is how big are those barriers and we have to measure the cost > associated with development of the conversion tools vs the likelihood that a > user will be willing to take on the rest of the effort (the final 10% and > re-test). My guess is that many users will simply not migrate unless they > are using jBPM in a "small way" or have issues causing them great pain in > jBPM 3. > >

17 years, 4 months

2
1
0 / 0

[Design of JBoss jBPM] - Re: SubjectAuthenticationService / ActorId from JAAS

by heiko.braun＠jboss.com

The resolver was a response to this question: anonymous wrote : | does it make sense at all to use the JAAS subject as actor? | It didn't mean to answer the JMS problem View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196150#4196150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196150

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: SubjectAuthenticationService / ActorId from JAAS

by camunda

anonymous wrote : But I assume this is not corrected now ;-) No, the changes doesn't have anything to do with the identity module... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196074#4196074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196074

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: SubjectAuthenticationService / ActorId from JAAS

by kukeltje

anonymous wrote : We decided for adding the authenticated actor to the JMS message (via JmsMessageFactory) and log in again in the MDB by reading the credentials from the JMS message... That is what I normally do as well. anonymous wrote : This code was "half baked" already there, and yes, it will be jbpm 3.3.1... The identity module is, service wise, half baked anyway (no offence Tom). There is no real interface that someone else could implement etc, hard coded things etc... But I assume this is not corrected now ;-) I'll check things out... tnx View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196070#4196070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196070

17 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev December 2008