June 2010 - jboss-dev-forums - Jboss List Archives

[jBPM Development] - variable declaration and history support

by Alejandro Guizar

Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] created the discussion "variable declaration and history support" To view the discussion, visit: http://community.jboss.org/message/547022#547022 -------------------------------------------------------------- A previous discussion touched the subject of https://jira.jboss.org/browse/JBPM-2506 JBPM-2506. While the proposed code looks great I noticed a particularity I wanted to discuss. ExecutionService has gained the following methods: /** creates or overwrites a variable value on the referenced execution and marks the variable to be stored in history*/ void setVariable(String executionId, String name, Object value, boolean historyEnabled); /** creates or overwrites the variable values on the referenced execution and marks the variables to be stored in history*/ void setVariables(String executionId, Map<String, ?> variables, boolean historyEnabled); These methods eventually reach a new overload for ScopeInstanceImpl.setVariable() public void setVariable(String key, Object value, boolean historyEnabled) { // ... if (variable!=null) { log.debug("updating variable '"+key+"' in '"+this+"' to value '"+value+"'"); variable.setValue(value, this); } else if (getParentVariableScope()==null) { createVariable(key, value, null, historyEnabled); } else { getParentVariableScope().setVariable(key,value, historyEnabled); } } Notice that, if the variable already exists, historyEnabled is ignored. On the other hand, ExecutionService does not expose the createVariable methods of ScopeInstanceImpl. Method createVariable is sometimes useful since setVariable always tries to create the variable in the parent scope. My proposal is to make the following additions to ExecutionService instead. This way we prevent historyEnabled from being ignored and expose useful new functionality. /** creates a variable value on the referenced execution. optionally marks the variable to be stored in history*/ void createVariable(String executionId, String name, Object value, boolean historyEnabled); /** creates variable values on the referenced execution. optionally marks the variables to be stored in history*/ void createVariables(String executionId, Map<String, ?> variables, boolean historyEnabled); -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547022#547022] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/547021#547021 -------------------------------------------------------------- > Ales Justin wrote: > > > 1) How to add this new RequirementDependencyItem (RDI) to existing Module's requirementDependencies? -- package protected > I guess this is all done as part of RDI::resolve, if actually resolved. > And there is no need to add this to initial Module? Moving WildcardDelegateLoader to same package as Module helps, but is it OK / valid? if (item.resolve(controller)) { List<RequirementDependencyItem> items = module.getDependencies(); // should not be null, as this delegate was created from a requirement items.add(item); module.addIDependOn(item); -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547021#547021] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/547017#547017 -------------------------------------------------------------- > 1) How to add this new RequirementDependencyItem (RDI) to existing Module's requirementDependencies? -- package protected I guess this is all done as part of RDI::resolve, if actually resolved. And there is no need to add this to initial Module? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547017#547017] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/547011#547011 -------------------------------------------------------------- > 2) How to get the DelegateLoader from resolved Module / RDI? OK, this one looks easy to solve: if (item.resolve(controller)) { Module resolvedModule = item.getResolvedModule(); if (resolvedModule instanceof ClassLoaderPolicyModule) { ClassLoaderPolicyModule clpm = (ClassLoaderPolicyModule) resolvedModule; DelegateLoader loader = clpm.getDelegateLoader(module, requirement); -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547011#547011] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports

by Ales Justin

Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion "Wildcard support in Dynamic-imports" To view the discussion, visit: http://community.jboss.org/message/547007#547007 -------------------------------------------------------------- > This fixes a lot of your TODOs above. :-.) The main TODOs are in the details -- using the delegate after that is the easy part. :-) 1) How to add this new RequirementDependencyItem (RDI) to existing Module's requirementDependencies? -- package protected 2) How to get the DelegateLoader from resolved Module / RDI? -- BaseCLPolicy::getExported? -- again protected 3) How add / remove this new DelegateLoader to / from host CLPolicy? -- protected, CLPolicy only has getter -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547007#547007] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - foreach activity

by Alejandro Guizar

Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] replied to the discussion "foreach activity" To view the discussion, visit: http://community.jboss.org/message/547005#547005 -------------------------------------------------------------- > Walter Seymore escribió: > I also thought the expression was a completion condition. Are you saying that the multiplicity attribute can be used in the same way? Let's say a rule execution determines that it should complete, would it be possible to write a multiplicity expression like this (pseudo code) "#{rule.result ? numberCompleted : items.size}"? The multiplicity expression can be used as a completion condition, but I know what you mean. It has to return an integer instead of a boolean. While the expression can read the process variables, requiring a numeric result makes completion conditions that depend on variables besides the number of joined executions rather cumbersome. On the other hand, the foreach examples provided so far can be resolved without a boolean completion condition. Plus, the multiplicity attribute was already present since version 4.0 of the jPDL schema. Relying on it for version 4.4 gives us time to discuss if we will need a more generic completion condition. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/547005#547005] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - foreach activity

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "foreach activity" To view the discussion, visit: http://community.jboss.org/message/546995#546995 -------------------------------------------------------------- > Walter Seymore wrote: > > I also thought the expression was a completion condition. Are you saying that the multiplicity attribute can be used in the same way? Let's say a rule execution determines that it should complete, would it be possible to write a multiplicity expression like this (pseudo code) "#{rule.result ? numberCompleted : items.size}"? > > Thanks > Walter It is more like surrounding activities that needs to be executed in a loop than attaching loop characteristic to an activity. Meaning that there are two sides with separated responsibilities: * for each activity that is responsible for creating required activity instances based on outgoing transition and expr attribute * join activity that is responsible for continuing the flow based on number of incoming transitions and multiplicity attribute Answering to your question, yes, you can use any expression that is supported by juel. Currently all evaluation on multiplicity attribute is done by JUEL script engine. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546995#546995] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - foreach activity

by Alejandro Guizar

Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] replied to the discussion "foreach activity" To view the discussion, visit: http://community.jboss.org/message/546994#546994 -------------------------------------------------------------- The patch is ready for review. Took a while to iron certain wrinkles out. Comments appreciated. I will reincorporate Maciej's documentation once we are past acceptance testing. > HuiSheng Xu wrote: > > BTW, when could we release the jBPM 4.4? We had already closed 80 issues, is it enough? More than enough, I would say. I'll try to commit this week to closing the remaining issues. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546994#546994] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [jBPM Development] - foreach activity

by Maciej Swiderski

Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion "foreach activity" To view the discussion, visit: http://community.jboss.org/message/546990#546990 -------------------------------------------------------------- fair enough. Now I have full picture of it. It is not big change after all, but make it more clear and it is more flexible since we can control both sides (creation and continuation). I think you covered all. There will be a need for slight update of the examples and docs. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546990#546990] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Installing JBossWS Native on JBAS 5.1.0

by Alessio Soldano

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "Installing JBossWS Native on JBAS 5.1.0" To view the discussion, visit: http://community.jboss.org/message/546983#546983 -------------------------------------------------------------- > ANIL SALDHANA wrote: > > If I need to integration testing with JBossWS, I would prefer to see an ant script that does not have many directories with a lot of duplicated jars and tests/docs etc. which duplicated jars? The only things I see that might seem "duplicated" (but actually are not) are the container integration related directories (deploy/resources/jbossws-jbossXYZ). Of course just one of them is used, depending on the selected target container. > The requirement is very simple - provide the least painful means to install the latest version of JBossWS on to an existing AS install. We do run integration testing using the binary distribution every night. We had an issue with 3.3.0 testing that went un-noticed (the reason being the hudson job not starting from a clean AS at every binary distribution installation), but that problem with testing is being resolved, while the actual issue in the distribution is fixed in 3.3.1 (available since yesterday). Besides that, installing the binary distribution for integration testing is really a matter of 2 commands: cp ant.properties.example ant.properties ant -Djboss510.home=/home/alessio/jboss-5.1.0.GA -Djbossws.integration.target=jboss510 deploy-jboss51 .. assuming you're using AS 5.1.0. Please note the contents in ant.properties are overwritten by the env props you provide to ant, so you don't need to edit ant.properties in a automatic job running the tests. If that really hurts, we can even try avoiding enforcing the copy of ant.properties.example when env props are provided. The rest does not seem that painfull to me. The script removes what needs to be removed from the AS and copies what needs to be copied. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546983#546983] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 10 months

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