[JBoss jBPM] - Re: Using Drools for jBPM decision
by turpin_vincent
For testing, i have recreate a Decision handler based on the code below:
16: public class DroolsDecisionHandler extends DroolsHandler implements
| 17: DecisionHandler {
| 18: private static final long serialVersionUID = -8900810376838166513L;
| 19:
| 20: public List<String> assertObjects;
| 21: public String workingMemoryName;
| 22:
| 23: public String decide(ExecutionContext executionContext)
| 24: throws Exception {
| 25: WorkingMemory workingMemory = getWorkingMemory(
| 26: workingMemoryName, assertObjects, executionContext);
| 27: workingMemory.setGlobal("decision", new Decision());
| 28: workingMemory.fireAllRules();
| 29: return ((Decision) workingMemory.getGlobal("decision"))
| 30: .getOutcome();
| 31: }
| 32:
| 33: }
|
And I have found that the executionContext was unable to solve my objects.
For example,
(Iteration on assertObjects)
| ContextInstance ci = executionContext.getContextInstance();
|
| while (iter.hasNext()) {
| objectName = (String) iter.next();
| object = ci.getVariable(objectName);
| System.out.println("object name is: " + objectName);
| workingMemory.assertObject(object);
| }
|
|
object are always null!
That shows me that object are never mapped!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217505#4217505
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217505
17 years, 2 months
[Microcontainer] - Ordering a deployer which needs multiple inputs
by jaikiran
If i have n number of deployers in a chain, is there a specific order these deployers follow while deploying an unit?
Right now, i have the following scenario:
public class FirstDeployer extends AbstractDeployer
| {
|
| public FirstDeployer()
| {
| setStage(REAL);
|
| // our only input is JBossMetaData
| setInput(JBossMetaData.class);
|
| // we generate FirstOutput.class as the output
| setOutput(FirstOutput.class);
| }
|
| public void deploy(DeploymentUnit unit)
| {
| // do something and add output
| unit.addAttachment(FirstOutput.class);
| }
|
| }
|
|
|
public class SecondDeployer extends AbstractRealDeployerWithInput<JBossMetaData>
| {
|
| public SecondDeployer()
| {
| // set a visitor
| setDeploymentVisitor(new SimpleVisitor());
|
| // we generate SecondOutput.class as the output
| setOutput(SecondOutput.class);
| }
|
| private class SimpleVisitor implements DeploymentVisitor<JBossMetaData>
| {
| public void deploy(DeploymentUnit unit, JBossMetaData jbmeta)
| {
| // we generate SecondOutput.class as the output
| unit.addAttachment(SecondOutput.class);
| }
|
| }
|
| }
|
public class FinalDeployer extends AbstractDeployer
| {
|
| public FinalDeployer()
| {
| setStage(REAL);
|
| // we rely on 2 inputs
| // 1) FisrtOutput.class Generated from FirstDeployer
| // 2) SecondOutput.class generated from SecondDeployer
| addInput(FirstOutput.class);
| addInput(SecondOutput.class);
|
| // we generate FinalOutput.class as the output
| setOutput(FinalOutput.class);
| }
|
| public void deploy(DeploymentUnit unit)
| {
| // we expect both the inputs to be present in the unit at this point
| FirstOutput one = unit.getAttachment(FirstOutput.class);
| SecondOutput second = unit.getAttachment(SecondOutput.class);
| }
|
| }
|
|
|
As can be seen:
* There are 3 deployers - FirstDeployer, SecondDeployer and FinalDeployer. Each are for the REAL stage.
* The FirstDeployer generates FirstOutput.class as output
* The SecondDeployer generates SecondOutput.class as output
* Ordering between FirstDeployer and SecondDeployer is NOT of concern in this example, since each one is independent
* The FinalDeployer expects 2 inputs - one from FirstDeployer and one from SecondDeployer. Ordering IS important here. So when FinalDeployer is invoked, for deploying the unit, it expects both the inputs to be available (as attachments) in the unit. So both the FirstDeployer and SecondDeployer should have processed the unit before reaching the FinalDeployer.
However, from what i see, the FinalDeployer is invoked before the SecondDeployer and hence when the FinalDeployer tries to get hold of SecondOutput, it gets a null.
Shouldn't the inputs add some sort of dependency/ordering within the deployers? More importantly, since the FinalDeployer relies on 2 inputs, shouldn't it be called only after *both* inputs are available? Right now, from the logs it appears to me that this FinalDeployer is being invoked when atleast one of the input is available.
As a ugly hack (for testing) i set the relative order for the FinalDeployer and i see that it gets called after both the FirstDeployer and SecondDeployer are invoked (the original intention).
public class FinalDeployer extends AbstractDeployer
| {
|
| public FinalDeployer()
| {
| setStage(REAL);
|
| // we rely on 2 inputs
| // 1) FisrtOutput.class Generated from FirstDeployer
| // 2) SecondOutput.class generated from SecondDeployer
| addInput(FirstOutput.class);
| addInput(SecondOutput.class);
|
| // we generate FinalOutput.class as the output
| setOutput(FinalOutput.class);
|
| // let's go last
| setRelativeOrder(Integer.MAX_VALUE);
| }
| ...
|
| }
|
|
By the way, the setRelativeOrder - what is it relative to?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217498#4217498
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217498
17 years, 2 months
[Management, JMX/JBoss] - Re: MBean depends on a stateless EJB
by kyle.bober
I am running into the same issuw as yourself. Were you able to figrue out a solution to this.
I too have a MBean that has a dependency on an Stateless EJB3 bean.
Snippet of the MBean
| @Service
| @Management(IChartServiceJMX.class)
| public class ChartServiceJMX implements IChartServiceJMX
| {
| /**
| * Logger for this class
| */
| private static final Logger LOGGER = Logger.getLogger(ChartServiceJMX.class);
|
| private ChartAdminService theChartAdminService;
|
| @Depends("jboss.j2ee:jndiName=ChartAdminServiceEJB,service=EJB3")
| public void setChartAdminService(ChartAdminService aChartAdminService)
| {
| this.theChartAdminService = aChartAdminService;
| }
|
Snippet of the EJB3 Bean
| @Stateless(mappedName="ChartAdminServiceEJB")
| @WebService(name="chartAdminService", serviceName="chartAdminService")
| @SOAPBinding(style=SOAPBinding.Style.DOCUMENT, use=SOAPBinding.Use.LITERAL, parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
| @TransactionManagement(TransactionManagementType.CONTAINER)
| public class ChartAdminService extends BaseService implements IChartAdminService
|
I receive the following when I attempt to deploy the EAR file that contains the EJB jar which contains the MBean and Stateless EJB3 Bean.
Thanks,
Kyle
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217486#4217486
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217486
17 years, 2 months