[Design of POJO Server] - JBAS-6297, mbean service optional injection
by scott.stark@jboss.org
I'm not understanding the current mc optional dependency implementation. I expected that I could simply leverage an optional notion from AbstractDependencyItem to update the ServiceInjectionValueMetaData.visit method to create an optional dependency like:
| public void visit(ServiceMetaDataVisitor visitor)
| {
| ServiceControllerContext context = visitor.getControllerContext();
| Object name = context.getName();
| ControllerState whenRequired = visitor.getContextState();
|
| boolean optional = isOptional();
| DependencyItem item = new AbstractDependencyItem(name, dependency, whenRequired, dependentState, optional);
| visitor.addDependency(item);
|
| visitor.visit(this);
| }
|
But optionality does not exist in AbstractDependencyItem. It only exists in a protected OptionalDependencyItem which is an inner class of the AbstractDependencyValueMetaData class. Why isn't this a general DependencyItem notion?
I guess I'll look at updating the ServiceInjectionValueMetaData.getValue to return null and see what additional changes are needed to deal with that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195198#4195198
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195198
17 years, 4 months
[Design of JBoss jBPM] - Re: Creatiing new pooled actors for every task instance
by stringaling
I have no issue with assignment at run time. In my mind the assignment is the join between the JBPM_POOLEDACTOR, and JBPM_TASKINSTANCE via the JBPM_TASKACTORPOOL.
Where I have issue is creating assignee's (POOLEDACTOR) when there are defined as part of the process definition. The fact that I declare a swimlane that defines a pooled_actor such as:
| <swimlane name="Fraud">
| <assignment pooled-actors="Fraud User"/>
| </swimlane>
|
would be a pretty good indication that this not going to change.
OK - I do understand that the list of pooled-actors can be determined at runtime via an expression, and in this case there is a need to store the actor at run times. But then why bother with the MANY-TO-MANY join then. Why not put the instance_id directly on the JBPM_POOLEDACTOR table. The same functionality could be achieved then with 2 joins instead of 3.
Here is an example of the query:
| <query name="TaskMgmtSession.findPooledTaskInstancesByActorId">
| <![CDATA[
| select distinct ti
| from org.jbpm.taskmgmt.exe.PooledActor pooledActor
| join pooledActor.taskInstances ti
| where pooledActor.actorId = :swimlaneActorId
| and ti.actorId is null
| and ti.isSuspended != true
| and ti.isOpen = true
| ]]>
| </query>
|
(from hibernate.queries.hbm.xml)
What the query hides is the MANY-TO-MANY table that is part of the hibernate mapping definition:
| ...
| <set name="pooledActors"
| cascade="all"
| table="JBPM_TASKACTORPOOL">
| <key column="TASKINSTANCE_" foreign-key="FK_TASKACTPL_TSKI"/>
| <many-to-many class="org.jbpm.taskmgmt.exe.PooledActor" column="POOLEDACTOR_" />
| ...
| </set>
|
(from TaskInstance.hbm.xml)
| <set name="taskInstances" inverse="true" table="JBPM_TASKACTORPOOL">
| <key column="POOLEDACTOR_" foreign-key="FK_TSKACTPOL_PLACT"/>
| <many-to-many class="org.jbpm.taskmgmt.exe.TaskInstance" column="TASKINSTANCE_" />
| </set>
|
(from PooledActor.hbm.xml)
The three joins is compounded by a 4th join that I need to do to properly implement paging within our application. :(
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195176#4195176
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195176
17 years, 4 months