June 2009 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: IdentityService API Usage update

by tom.baeyens＠jboss.com

yes. the identity component creates the ids for the groups. it's component dependent. jbpm built-in uses String groupId = groupType != null ? groupType + "." + groupName : groupName; View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236983#4236983 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236983

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: IdentityService API Usage update

by kukeltje

Hmm... does this mean the JBoss idm creates the groupId? I hope there is some nice logic behind it and not some 'hash' thingy (I've not looked at the JBoss idm code so forgive me if my remark is bs ;-)) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236951#4236951 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236951

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by jbarrez

Sorry, didnt know about the AsyncCommandService, should've checked before posting ;-) anonymous wrote : There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself. Isn't this confusing to have 2 process engines for people that want to use both sync and async commands (altough the use cases are limited, but they do exist). Can't the services returned by the processEngine be sync or async? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236930#4236930 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236930

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by tom.baeyens＠jboss.com

Commands and CommandService are not necessary to give the user the capability of async commands. There is already an AsyncCommandService, but it should be hidden behind the other services. So I would translate your point into: There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236929#4236929 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236929

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by jbarrez

I believe we shouldn't impose a fixed sync/async way of working on the users of the remote api. I also think that usng a method param to change to async invocation is cumbersome for most users. So, perhaps we should create a sync CommandService and an Async CommandService? I'm also in favour of using EJB3. Since the commandservice normally is behind the service interfaces ... why not use a modern and cool implementation where everybody loves to work with? EJB3 runs today on all app servers I'm aware of (JBoss, Glassfish, Oracle, IBM, ...). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236925#4236925 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236925

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by tom.baeyens＠jboss.com

also async commands can be done behind the same interface. in that case, the command service can be replaced with a version that sends an async message to the job executor to execute the job asynchronously. in that case you have to choose if you want to use the whole api asynchronously or not. i'm not yet sure if we have to introduce a way to let users choose async or not on a method by method basis... wdyt ? the code is present but not yet tested/documented. that's for later as that doesn't have a priority yet. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236916#4236916 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236916

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: IdentityService API Usage update

by tom.baeyens＠jboss.com

perfect. go ahead. thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236897#4236897 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236897

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - IdentityService API Usage update

by jeff.yuchang

Hi all, Noted from the test cases code, we all use the groupName as groupId by default, this is fine with the jbpm-built-in implementation, as these two are the same, but they are different in the jboss idm implementation. So I am going to update those test cases, using the groupId, instead of groupName, take org.jbpm.examples.mail.inline.InlineMailTest.java for example: | identityService.createGroup("thinkpol"); | identityService.createGroup("innerparty"); | identityService.createMembership("obrien", "thinkpol"); | identityService.createMembership("charr", "innerparty"); | identityService.createMembership("obrien", "innerparty"); | I will updated it as: | String groupId1 = identityService.createGroup("thinkpol"); | String groupId2 = identityService.createGroup("innerparty"); | identityService.createMembership("obrien", groupId2); | identityService.createMembership("charr", groupId1); | identityService.createMembership("obrien", groupId1); | Any comments on this update? any objections?? Thanks Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236891#4236891 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236891

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by camunda

Okay, I have to investigate a bit more here as well. But i still think, there is a use case to use the CommandService, e.g. - sending Commands either via JMS asynchronously or execute the synchronously (think of batch operations) - migration from jbpm 3, would be possible to write a simple "CommandTranslator" and plug it in the CommandService, so you don't have to change existing client code using Commands (okay, maybe you have to change some, but not all) So basically I like the CommandService and want to keep it for sure in the API, don't make it internal please. And I still would like to see an EJB3 implementation. For us, the development team, to make it easier but as well for marketing purposes (even if you don't see it in the code, the people ask what runs under the hood). But maybe it doesn't have a high priority, ok... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236879#4236879 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236879

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

by kukeltje

hmmm... ok, I did not know this. Time for me to start reading some more. I was under the same impression as Bernd and thinking about using the same approach. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236867#4236867 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236867

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev June 2009