[JBoss jBPM] - Re: From
by unsavory
I've found the issue in the source. There is a bug in the code in JoinBinding.java
Here is the defective source for that class:
public Object parse(Element element, Parse parse, Parser parser) {
| JoinActivity joinActivity = new JoinActivity();
|
| if (element.hasAttribute("multiplicicty")) {
| String multiplicictyText = element.getAttribute("multiplicicty");
| try {
| int multiplicity = Integer.parseInt(multiplicictyText);
| joinActivity.setMultiplicity(multiplicity);
| } catch (NumberFormatException e) {
| parse.addProblem("multiplicity "+multiplicictyText+" is not a valid integer", element);
| }
| }
|
| if (element.hasAttribute("lockmode")) {
| String lockModeText = element.getAttribute("lockmode");
| LockMode lockMode = LockMode.parse(lockModeText.toUpperCase());
| if (lockMode==null) {
| parse.addProblem("lockmode "+lockModeText+" is not a valid lock mode", element);
| } else {
| joinActivity.setLockMode(lockMode);
| }
| }
|
| return joinActivity;
| }
Should be multiplicity, not multiplicicty. I'll open a JIRA if/when I get a chance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249507#4249507
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249507
16 years, 10 months
[Installation, Configuration & DEPLOYMENT] - well, i tried that and as i feared this happend:
by Elhanan
after placing jboss-aop.xml in the meta-inf of the ear which contained this:
<jboss-app>
<loader-repository>
com.pnx:archive=underwrite.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
the deployment failed with mdbeans:
21:01:59,956 WARN [verifier] EJB spec violation:
Bean : LCRequestHandlerMDB
Section: 15.7.4
Warning: The message driven bean must declare one onMessage() method.
21:01:59,956 WARN [verifier] EJB spec violation:
Bean : LCResponseHandlerMDB
Section: 15.7.4
Warning: The message driven bean must declare one onMessage() method.
org.jboss.deployment.DeploymentInfo@74cef1f3 { url=file:/C:/Workdir/jboss/jboss-4.2.3/server/pmp/deploy/underwrite.ear/framework-ejb.jar/ }
deployer: MBeanProxyExt[jboss.ejb:service=EJBDeployer]
status: Deployment FAILED reason: Verification of Enterprise Beans failed, see above for error messages.
state: FAILED
watch: file:/C:/Workdir/jboss/jboss-4.2.3/server/pmp/deploy/underwrite.ear/framework-ejb.jar/META-INF/ejb-jar.xml
altDD: null
lastDeployed: 1250186505465
lastModified: 1250084967802
mbeans:
rg.jboss.deployment.DeploymentInfo@7eaeb79f { url=file:/C:/Workdir/jboss/jboss-4.2.3/server/pmp/deploy/underwrite.ear/ }
deployer: org.jboss.deployment.EARDeployer@1b8119a
status: Deployment FAILED reason: Verification of Enterprise Beans failed, see above for error messages.
state: FAILED
watch: file:/C:/Workdir/jboss/jboss-4.2.3/server/pmp/deploy/underwrite.ear/META-INF/application.xml
altDD: null
lastDeployed: 1250186519613
lastModified: 1250084971775
mbeans:
here the mdb's defintions:
<message-driven>
<ejb-name>LCRequestHandlerMDB</ejb-name>
<ejb-class>com.pnx.pmp.jms.backend.mdb.LCRequestHandlerMDB</ejb-class>
<transaction-type>Bean</transaction-type>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
</message-driven>
<message-driven>
<ejb-name>LCResponseHandlerMDB</ejb-name>
<ejb-class>com.pnx.pmp.jms.backend.mdb.LCResponseHandlerMDB</ejb-class>
<transaction-type>Bean</transaction-type>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
</message-driven>
<message-driven>
<ejb-name>LCRequestHandlerMDB</ejb-name>
<destination-jndi-name>queue/underwrite/LegacyCallRequestQueue</destination-jndi-name>
</message-driven>
<message-driven>
<ejb-name>LCResponseHandlerMDB</ejb-name>
<destination-jndi-name>queue/underwrite/LegacyCallResponseQueue</destination-jndi-name>
</message-driven>
underwrite/LCRequestConnectionFactory
ConnectionFactory
underwrite/LCResponseConnectionFactory
ConnectionFactory
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249503#4249503
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249503
16 years, 10 months
[EJB 3.0] - Re: Many to Many realtionship question
by EladKatz
Hi jaikiran,
Thanks for the quick reply, I have actually read this article before and indeed in my implementation I use Sets instead of a Collection as is recommended there.
However, that article doesn't address my issue directly though it does say this:
anonymous wrote :
| For a @ManyToMany relationship, it might look like this:
|
| LeftBean left = ...;
| | RightBean right = ...;
| | left.getRights().add(right);
| | right.getLefts().add(left);
| |
| | this.entityManager.merge(left);
|
which means that if I want to add multiple records to the left bean i would have to add it once in the right bean and for each of the left records i'm going to have to add this right bean to them, and then only commit (merge) one of them.
that will work, but feels wrong - is this really the case?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249500#4249500
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249500
16 years, 10 months
[JBoss jBPM] - Re: From
by unsavory
No, it does not. I have tried so many different ways of getting this to work but with no success. No matter what I do, I cannot get it to move past the join.
Here is an updated process flow that I am trying to simplify things:
<fork name="agreement complete">
| <transition name="to screen applicant" to="screen applicant" />
| <transition name="to complete zh language exam" to="complete zh language exam" />
| </fork>
|
| <task name="complete zh language exam" assignee="#{ user.stringId }">
| <transition name="complete" to="screening join" />
| </task>
|
| <task name="screen applicant" assignee="12345">
| <transition name="complete" to="screening join" />
| <transition name="reject" to="rejected" />
| </task>
|
| <join name="screening join">
| <!-- <transition name="to screen applicant" to="screen applicant" /> -->
| <transition name="to hire applicant" to="hire applicant" />
| </join>
|
| <task name="hire applicant" assignee="12345">
| <transition name="complete" to="complete" />
| <transition name="reject" to="rejected" />
| </task>
After completing both tasks in the fork i have a root execution that is in status "inactive-concurrent-root" and two child executions both in status "inactive-join". I know that both tasks have been completed because I can see them in the task history.
Upon completion of "screen applicant", here are my logs:
anonymous wrote : 10:39:33,268 DEBUG ExecuteActivity:60 - execution[USOnboarding.238256.to screen applicant] executes activity(screening join)
| Hibernate: /* UPGRADE lock org.jbpm.pvm.internal.model.ExecutionImpl */ select DBID_ from JBPM4_EXECUTION where DBID_ =? and DBVERSION_ =? for update
| Hibernate: /* select deploymentProperty from org.jbpm.pvm.internal.repository.DeploymentProperty as deploymentProperty where deploymentProperty.key = 'pdid' and deploymentProperty.stringValue = 'USOnboarding-6' */ select deployment0_.DBID_ as DBID1_5_, deployment0_.DEPLOYMENT_ as DEPLOYMENT2_5_, deployment0_.OBJNAME_ as OBJNAME3_5_, deployment0_.KEY_ as KEY4_5_, deployment0_.STRINGVAL_ as STRINGVAL5_5_, deployment0_.LONGVAL_ as LONGVAL6_5_ from JBPM4_DEPLOYPROP deployment0_ where deployment0_.KEY_='pdid' and deployment0_.STRINGVAL_='USOnboarding-6' limit ?
| Hibernate: /* load one-to-many org.jbpm.pvm.internal.task.TaskImpl.participations */ select participat0_.TASK_ as TASK6_1_, participat0_.DBID_ as DBID1_1_, participat0_.DBID_ as DBID1_7_0_, participat0_.DBVERSION_ as DBVERSION2_7_0_, participat0_.GROUPID_ as GROUPID3_7_0_, participat0_.USERID_ as USERID4_7_0_, participat0_.TYPE_ as TYPE5_7_0_, participat0_.TASK_ as TASK6_7_0_, participat0_.SWIMLANE_ as SWIMLANE7_7_0_ from JBPM4_PARTICIPATION participat0_ where participat0_.TASK_=?
| Hibernate: /* load one-to-many org.jbpm.pvm.internal.task.TaskImpl.variables */ select variables0_.TASK_ as TASK8_1_, variables0_.DBID_ as DBID1_1_, variables0_.KEY_ as KEY4_1_, variables0_.DBID_ as DBID1_1_0_, variables0_.DBVERSION_ as DBVERSION3_1_0_, variables0_.KEY_ as KEY4_1_0_, variables0_.CONVERTER_ as CONVERTER5_1_0_, variables0_.HIST_ as HIST6_1_0_, variables0_.EXECUTION_ as EXECUTION7_1_0_, variables0_.TASK_ as TASK8_1_0_, variables0_.DATE_VALUE_ as DATE9_1_0_, variables0_.DOUBLE_VALUE_ as DOUBLE10_1_0_, variables0_.LONG_VALUE_ as LONG11_1_0_, variables0_.STRING_VALUE_ as STRING12_1_0_, variables0_.TEXT_VALUE_ as TEXT13_1_0_, variables0_.LOB_ as LOB14_1_0_, variables0_.CLASS_ as CLASS2_1_0_ from JBPM4_VARIABLE variables0_ where variables0_.TASK_=?
| Hibernate: /* load one-to-many org.jbpm.pvm.internal.task.TaskImpl.subTasks */ select subtasks0_.SUPERTASK_ as SUPERTASK18_1_, subtasks0_.DBID_ as DBID1_1_, subtasks0_.DBID_ as DBID1_6_0_, subtasks0_.DBVERSION_ as DBVERSION3_6_0_, subtasks0_.NAME_ as NAME4_6_0_, subtasks0_.DESCR_ as DESCR5_6_0_, subtasks0_.STATE_ as STATE6_6_0_, subtasks0_.SUSPHISTSTATE_ as SUSPHIST7_6_0_, subtasks0_.ASSIGNEE_ as ASSIGNEE8_6_0_, subtasks0_.FORM_ as FORM9_6_0_, subtasks0_.PRIORITY_ as PRIORITY10_6_0_, subtasks0_.CREATE_ as CREATE11_6_0_, subtasks0_.DUEDATE_ as DUEDATE12_6_0_, subtasks0_.PROGRESS_ as PROGRESS13_6_0_, subtasks0_.SIGNALLING_ as SIGNALLING14_6_0_, subtasks0_.EXECUTION_ID_ as EXECUTION15_6_0_, subtasks0_.ACTIVITY_NAME_ as ACTIVITY16_6_0_, subtasks0_.HASVARS_ as HASVARS17_6_0_, subtasks0_.SUPERTASK_ as SUPERTASK18_6_0_, subtasks0_.EXECUTION_ as EXECUTION19_6_0_, subtasks0_.PROCINST_ as PROCINST20_6_0_, subtasks0_.SWIMLANE_ as SWIMLANE21_6_0_, subtasks0_.TASKDEFNAME_ as TASKDEF22_6_0_ from JBPM4_TASK subtasks0_ where subtasks0_.SUPERTASK_=?
| Hibernate: /* update org.jbpm.pvm.internal.history.model.HistoryTaskImpl */ update JBPM4_HIST_TASK set DBVERSION_=?, EXECUTION_=?, OUTCOME_=?, ASSIGNEE_=?, PRIORITY_=?, STATE_=?, CREATE_=?, END_=?, DURATION_=?, NEXTIDX_=? where DBID_=? and DBVERSION_=?
| Hibernate: /* update org.jbpm.pvm.internal.history.model.HistoryTaskInstanceImpl */ update JBPM4_HIST_ACTINST set DBVERSION_=?, HPROCI_=?, TYPE_=?, EXECUTION_=?, ACTIVITY_NAME_=?, START_=?, END_=?, DURATION_=?, TRANSITION_=?, NEXTIDX_=?, HTASK_=? where DBID_=? and DBVERSION_=?
| Hibernate: /* update org.jbpm.pvm.internal.model.ExecutionImpl */ update JBPM4_EXECUTION set DBVERSION_=?, ACTIVITYNAME_=?, PROCDEFID_=?, HASVARS_=?, NAME_=?, KEY_=?, ID_=?, STATE_=?, SUSPHISTSTATE_=?, PRIORITY_=?, HISACTINST_=?, PARENT_=?, INSTANCE_=?, SUPEREXEC_=?, SUBPROCINST_=? where DBID_=? and DBVERSION_=?
| Hibernate: /* delete org.jbpm.pvm.internal.task.TaskImpl */ delete from JBPM4_TASK where DBID_=? and DBVERSION_=?
I've been struggling with this for 3 days now. Does anyone have a clue as to what might be happening here?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249499#4249499
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249499
16 years, 10 months
[JNDI/Naming/Network] - Re: Understand JNDI naming convention
by PeterJ
1) For each web app deployed to the app server there is a "java:comp" namespace whose content is accessible only by that app. The app server prefills some names but you have to do some work (such as add resource-ref entries to your web.xml) to get others.
mapped-name for what? In an @Stateless annotation? In an @EJB annotation? mapped-name is usually the full JNDI name (usefull for referencing the global namespace) while name is within the "java:" namespace for the app.
2) Names in the global namespace are accessible from remote clients (that is, running in a separate JVM) - remote clients cannot access names in "java:*". For example, if a remote client needs access to an EJB, it must look up the name in the global namespace.
3) You never said exactly where you are seeing this entry (I don't see it), but if it is part of the description for a"java:comp" then it is the name of the MBean name created for the application. MBean names have the pattern:
<namespace>:<key-value-pair>[,<key-value-pair>]*
so in your case "e.cache" is the namespace, and there is only one key-value pair "service=CacheLoader"
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249497#4249497
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249497
16 years, 10 months