February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: task and swimlane roles

by tom.baeyens＠jboss.com

i'll take this rout for this iteration. let's evaluate after the release. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210613#4210613 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210613

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process definition as a resource

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : I am very much in favor of what you call "Persistent Process Resource", which basically means just storing execution state and history in the DB. | Anything else, and most importantly, all class resources should be retrieved through the classloader. This already answers your question regarding the clustering: Leave it to the deployment/classloading framework of the AS. | downside is that this would not support process versioning as we're used to. (at least not without hacks) maybe we should consider support this as a separate execution mode. so if we assume that versioning is done by the client in the process file, then this would really fit the jboss deployer architecture. (finally !) "heiko.braun(a)jboss.com" wrote : But in general we should aim at the plain non clustered AS integration first | and then worry about clustering when we need it. You can easily relay questions like this if you leverage the AS infrastructure too a large degree. | if possible, we should look at the DB for clustering. if we stick with that, they our clustering works in any environment. so those type of solutions are preferrable. but on top of that, we can always look at how we can improve jboss specific clustering. (like described above) "heiko.braun(a)jboss.com" wrote : I do actually have uncommitted AS integration code on my disk, that installs the process engine as a service and adds the corresponding deployers so that you can drop *.par archives into the deploy folder. Quiet similiar to what Bernd described in his Blog, just for AS 5. | loading versioned classes lead to real complex solutions. and i'm not sure if those tricky things are justified. if a user deploys a new version of a process, it's always possible to update the classnames that are referenced and append _V2 or something to the classname. users can always reference new classes by pointing to different classnames. and then we don't have to come up with the very complex classloading to load similarly named classes in different process definition scopes. "heiko.braun(a)jboss.com" wrote : I would say, to begin with we should aim at | | 1) Persistent Process Resource as execution mode inside the AS | 2) Add a service and deployer | 3) Fix the classloading (classloader registry, reassociation upon reboot) | 4) Deal with different versioning strategies upn deployment and server boot. | | We need to get this sorted before diving into clustering topics. you're forgetting the basic BPM Suite use case: if you want the process versioning to work on every platform to give a non-coding-only-poin-and-click demo, then you need the dynamic persistent use case. so that should be 0) and for the next efforts, i indeed agree with your list View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210608#4210608 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210608

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process definition as a resource

by heiko.braun＠jboss.com

I am very much in favor of what you call "Persistent Process Resource", which basically means just storing execution state and history in the DB. Anything else, and most importantly, all class resources should be retrieved through the classloader. This already answers your question regarding the clustering: Leave it to the deployment/classloading framework of the AS. But in general we should aim at the plain non clustered AS integration first and then worry about clustering when we need it. But you easily relay questions like this if you leverage the AS infrastructure too a large degree. I do actually have uncommitted AS integration code on my disk, that installs the process engine as a service and adds the corresponding deployers so tat you can drop *.par archives intio the deploy folder. Quiet similiar to what Bernd described in his Blog, just for AS 5. I would say, to begin with we should aim at 1) Persistent Process Resource as execution mode inside the AS 2) Add a service and deployer 3) Fix the classloading (classloader registry, reassociation upon reboot) 4) Deal with diferent versioning strategies upn deployment and server boot. We need to get this sorted before diving into clustering topics. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210594#4210594 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210594

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - task and swimlane roles

by tom.baeyens＠jboss.com

heiko, i'm splitting the user and group roles. does this look ok to you ? public enum RoleType { | | USER, | | GROUP | | } In TaskService: /** add a role to a given task. | * @param roleType identifies if this is a user role or a group role | * @param refId identifies the user or group | * @param role specifies the role that the user or group fullfills for this task. */ | void addTaskRole(long taskDbid, String refId, RoleType roleType, String role); | | /** get roles related to a given task. | * @param roleType if not null it will filter the roles | * @param role if not null it will filter the roles */ | List<UserRole> getTaskRoles(long taskDbid, RoleType roleType, String role); | | /** removes a role to a given task. Nothing happens (no exception) if | * the role does not exist. | * @param roleType identifies if this is a user role or a group role | * @param refId identifies the user or group | * @param role specifies the role that the user or group fullfills for this task. */ | void removeTaskRole(long taskDbid, String refId, RoleType roleType, String userRoleType); | then the same methods for associating roles with swimlanes void addSwimlaneRole(long taskDbid, String refId, RoleType roleType, String role); | List<UserRole> getSwimlaneRoles(long taskDbid, RoleType roleType, String role); | void removeSwimlaneRole(long taskDbid, String refId, RoleType roleType, String userRoleType); does this make sense in the context of the discussions we had about it ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210593#4210593 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210593

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Redeploy is done wrong

by alesj

Actually dreaming about it some more :-), this is not good either. It would be just the other way around then, the old one seeing the new contents. e.g. * we see it's a redeploy --> DeploymentContext::prepareClean --> reset existing zip contexts * do structure recognition on the same root, same zip contexts --> re-initializing entries * undeploy on the same root/zip context == it sees the new enitres <---- X In most cases it would probably work, as you mostly change metadata, but if someone actually changed underlying jar file and then tried to load some newly non-existing resources at undeploy, it would break. I guess this could all be solved by having a temp copy all the time, but that's just the opposite of why we have vfs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210586#4210586 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210586

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: process definition as a resource

by kukeltje

"tom.baeyens(a)jboss.com" wrote : jbpm users typically deploy the process to the db and then store the instances in the DB as well. | I think most do not realy do this 'on purpose'. It's how it works. "tom.baeyens(a)jboss.com" wrote : | another aspect that becomes more complicated in 'persistent process resource' execution mode is deployment in a clustered environment. when using the DB to store process definitions, this is the single entry point accessible from all nodes. but how would we deploy a resource to all nodes in a cluster ? and how would the process definitions be cached in memory ? | Uhhmm.... JBoss Cache? Funny is that I kind of semi use jBPM in this resource way. I extend the processdefinition with my own xml tags for which I do not develop a specific jpdl parser or whatever. Runtime, I read the xml nodes with xpath from the processdefinition in the processarchive (will show this in the presentation also on the community day) I'll think about the other thinks though. Not fully grasp all differences yet, but that might be because it is to late (04:00 am) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210560#4210560 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210560

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBREFLECT-50, determining need for setAccessible bug

by scott.stark＠jboss.org

I worked around it for the JBAS-6285 case by updating the managed object factory to accept an interface that is to be used for the BeanInfo generation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210558#4210558 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210558

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBREFLECT-50, determining need for setAccessible bug

by scott.stark＠jboss.org

And speaking of running under a security manager, the SetAccessible PrivilegedAction in ReflectMethodInfoImpl should not be used because the security check should not be based on the jboss-reflect codebase. It needs to be based on the codebase calling into the reflection layer, and in reality, the code that is actually doing the invocation. I can see a general jboss layer like the management layer needing to obtain the reflection view, but the determination as to whether setAccessible can be called should be done when the invocation is made to validate that the caller codebase wanting to access or set a property value is not bypassing the underlying bean class java language security declarations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210537#4210537 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210537

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBREFLECT-50, determining need for setAccessible bug

by scott.stark＠jboss.org

We would have to do a lot more work to identify methods that are part of an interface as its not readily available from the Class or Method objects. I did test that if you obtain the Method object from the interface that this can be used to reflect on the instance of the non-public class without having to call setAccessible. A proper fix would probably have to consider whether methods belong to an interface or else when running under a security manager one would have to grant ReflectPermission("suppressAccessChecks") to contexts that should not need it. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210535#4210535 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210535

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-1495 - Replicate Expiry and DLQ

by timfox

JMX is optional, not management. You don't have to call management, but management and your code should share the same code for expiry/dlq, and this should be replicated when the server is clustered. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210534#4210534 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210534

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009