June 2009 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by kukeltje

I agree with Tom about the showing of variables. Afaik, the jsf console does the same. The suggestion about the constraints regarding processdeployments is a valid one as well. Would the 'assume nothing, expect everything' be a good approach? Like there *can* be a processimage or there can be forms but if one is not there, at least show a decent error? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238141#4238141 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238141

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by tom.baeyens＠jboss.com

from a prioritization perspective, first focus should be to complete this list of functionalities http://www.jboss.org/community/wiki/GWTConsoleFeatureSet if for those functionalities something is lacking in the core engine, discuss it and we'll deal with it. another aspect that i want to see prioritized is that the example processes all should be fully executable using the console only. for showing the process variable values, you can do introspection on the actual values that you get. you could render strings, numbers and dates and just use toString for all the other types. process variable editing can be addressed later. that is not a priority i think. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238133#4238133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238133

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by heiko.braun＠jboss.com

That's right, the docs are still missing. Some of the functionality is only available in particular situations, i.e: - depending on the process itself (i.e task forms) - the type & contents of process deployments (i.e. process image) - plugin functionality (forms) Before you go ahead a d discuss UI elements, it would make more sense to think about meaningful constraints, that can be applied to process deployments. Currently the console has to cope with a lot of unknowns, which derive from the "everything possible, but nothing mandatory" style of coding that jbpm4 reflects. Up to now I tried to include functionality in the console that is applicable to most of the use cases, but of course there is much more do add. However if it only applies to a small percentage of use cases and furthermore isn't even constrained to a certain degree we cannot simply add it. I'll give you an example: Process variable inspection is one of those cases. There is currently no constraint on variables whatsoever. The "hashmap" style of design allows for everything and nothing at the same time. Of course it would be useful have that feature in the console, but without any type descriptions associated with the process it will only work in particular situations and break in others. I can list plenty of other features that have been hold back, because the core codebase doesn't allow for reliable hook into runtime inspection. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238129#4238129 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238129

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: JBPM4 - singleton object from wirecontext

by tom.baeyens＠jboss.com

that is not a target functionality for our environment / wirecontext View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238107#4238107 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238107

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Extending jBPM, Plugging in custom IdentityService imple

by tom.baeyens＠jboss.com

here's pointers on how to plug your own identity service in jbpm.cfg.xml, remove the line <import resource="jbpm.identity.cfg.xml" /> and add <transaction-context> | <object class="your.package.YourIdentitySessionImpl" /> | </transaction-context> | YourIdentitySessionImpl should implement org.jbpm.pvm.internal.identity.spi.IdentitySession Making this identity pluggable is not our first target, but it was taken into the design. Let us know how it goes. I'll add these notes to the developers guide. And update them with your feedback. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238106#4238106 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238106

17 years

1
0
0 / 0

[Design of JBoss jBPM] - JBPM4 - singleton object from wirecontext

by galanfish

Hello, All! In the same environment, the same object should be returned when we request with the same objectName; But now I want to receive newly created object(as consumable) from the wireContext every time I request for, Is this configurable or I have to modify the source code or? thx in advanced! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238104#4238104 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238104

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Extending jBPM, Plugging in custom IdentityService implement

by shekharv

I was trying to identify how one could extend the current jbpm identity implementation or plugin one's own IdentityServiceImpl. I dug around in the code a bit and noticed that there are a couple of bindings.xml files that really are responsible for configuring what Implementation classes are responsible for each of the high level Service interfaces that we have in jBPM. TaskService, ExecutionService, etc. jbpm.wire.bindings.xml jbpm.user.bindings.xml Had a few points to note about the approach mentioned above, 1.) Is this the intent of the designers of the system and the api developers to provide extension points into the engine in this manner? 2.) There is also the jbpm.user.bindings.xml. From the looks of how the bindings are being stored(as a list) it does not seem that any bindings that we add to this file would override the bindings in the jbpm.wire.bindings.xml. So it seems to be more of an additive nature than overriding. So you could add new bindings, but you cannot replace/override the ones that the engine sets up by itself(default wire.bindings.xml) 3.)Taking the above point into consideration, should the jbpm.wire.bindings.xml be user configurable option? If needed? So that there is a more straightforward way to 'register' one's custom implementations for Identity and other Services(If needed). Or should the jbpm.user.bindings.xml be loaded in such a manner that it can override the existing ones. So store the bindings in a Map rather than a List? All this is based on my understanding of the way things are being setup within the engine, we have really been working with jbpm4 for a little over a week now. So I could be really miles away from the truth and the bigger picture. Excuse me if that is the case. Plugging in a custom IdentityServiceImpl would be a big gain if we are able to hook it up seamlessly to work with our own auth mechanism. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238088#4238088 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238088

17 years

1
0
0 / 0

No more jBPM 3 releases?

by Ronald van Kuijk

>From https://jira.jboss.org/jira/browse/JBPM-2263 Tom Baeyens<https://jira.jboss.org/jira/secure/ViewProfile.jspa?name=tom.baeyens%40jb...>- 15/Jun/09 03:45 AM there are no more releases planned for jbpm 3 Is this true? Only SP releases for bugfixes? But isn't this a 'bug'? The schema allows it.

17 years

5
7
0 / 0

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by jeff.yuchang

"kukeltje" wrote : | | Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations. Thanks for the info, yes, this is a totally valid point.. now I see the bad result of imposing constraints on the groupId. ;-) thanks Jeff View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237825#4237825 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237825

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by bdaw

In JBoss IDM when you plug LDAP you point groupID for a specific tree part. Then you would refer to configured groupType and simply use the CN part as groupID. Id needs to be unique in scope of groupType so this fits. I think jbpm could allow non constrained ids and just force composite ids for idm integration. then in situation when you plag few different identity stores and map group types to them you need to have some way to discover where they belong anyway. And groupType in composite key allows this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237821#4237821 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237821

17 years

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 June 2009