[
https://jira.jboss.org/browse/JBPM-2946?page=com.atlassian.jira.plugin.sy...
]
Alejandro Guizar resolved JBPM-2946.
------------------------------------
Assignee: Alejandro Guizar
Fix Version/s: (was: jBPM 3.2.10)
Resolution: Rejected
The JNDI name deemed «hardcoded» is in fact an EJB reference name, cf. EJB 2.1 section
20.3. In JBoss AS, EJB references can be bound to a named bean of the appropriate type in
ejb-jar.xml. The next snippet comes from
http://anonsvn.jboss.org/repos/jbpm/jbpm3/branches/jbpm-3.2-soa/enterpris...
<session>
<ejb-name>CommandServiceBean</ejb-name>
</session>
<message-driven>
<ejb-name>CommandListenerBean</ejb-name>
[...]
<ejb-local-ref>
<ejb-ref-name>ejb/LocalCommandServiceBean</ejb-ref-name>
<ejb-link>CommandServiceBean</ejb-link>
</ejb-local-ref>
</message-driven>
If the target bean is not declared in the same deployment unit, the EJB reference can be
bound to a global JNDI name in jboss.xml, as in the following fragment.
<ejb-local-ref>
<ejb-ref-name>ejb/LocalCommandServiceBean</ejb-ref-name>
<local-jndi-name>java:jbpm/CommandServiceBean</local-jndi-name>
</ejb-local-ref>
EJB references are a standard coding practice. Since the referenced object can be changed
already at deployment time, there is no need to make the reference name customizable.
Additionally, if the reference name was to be made customizable, jbpm.cfg.xml would be a
bad choice because the command service bean is instantiated by the EJB container, not by
the jBPM object factory.
class org.jbpm.ejb.impl.CommandListenerBean.java the lookup has the
JNDI name harcoded
--------------------------------------------------------------------------------------
Key: JBPM-2946
URL:
https://jira.jboss.org/browse/JBPM-2946
Project: jBPM
Issue Type: Patch
Security Level: Public(Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 3.2.x
Reporter: eric schabell
Assignee: Alejandro Guizar
Priority: Minor
Working with jBPM 3.2.8 but I have found it still is the same in jBPM 3.x TRUNK. This
issue was raised in issue 00063190, but is resolved in JBoss environments only with their
answer. To be more flexible the fix below would be nice.
Class org.jbpm.ejb.impl.CommandListenerBean.java the lookup has the JNDI name harcoded:
LocalCommandServiceHome commandServiceHome = (LocalCommandServiceHome)
initial.lookup("java:comp/env/ejb/LocalCommandServiceBean");
So this can't be configured through jbpm-cfg.xml. This causes problems when the EJB
JNDI name is different from ejb/LocalCommandServiceBean.
I wonder if it's possible to fix it so it works like the
org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory.java, which has this:
String timerEntityHomeJndiName = "java:comp/env/ejb/TimerEntityBean";
[...]
timerEntityHome = (LocalTimerEntityHome) lookup(timerEntityHomeJndiName);
This way it can be configured through jbpm-cfg.xml:
<service name="scheduler">
<factory>
<bean class="org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory">
<field name="timerEntityHomeJndiName">
<string value="TimerEntityBean"/>
</field>
</bean>
</factory>
</service>
This is sort of like the issue resolved here
https://jira.jboss.org/browse/JBPM-960
Patch would be something like this in CommandListenerBean.java starting at line 179
(entire method provided here):
private Session createSession() throws JMSException {
if (jmsConnection == null) {
// lookup factory and create jms connection
try {
log.debug("trying to create session with CommanListenerBean");
Context initial = new InitialContext();
// Changed the following line to change the hardcoded comp:env/ejb JNDI
// ConnectionFactory jmsConnectionFactory = (ConnectionFactory)
initial.lookup("java:comp/env/jms/JbpmConnectionFactory");
ConnectionFactory jmsConnectionFactory = (ConnectionFactory)
initial.lookup("jbpmJobExecConFact");
jmsConnection = jmsConnectionFactory.createConnection();
log.debug("done creating session with CommanListenerBean");
}
catch (NamingException e) {
throw new EJBException("error retrieving jms connection factory", e);
}
}
/*
* if the connection supports xa, the session will be transacted, else the session
will auto
* acknowledge; in either case no explicit transaction control must be performed -
see ejb 2.1 -
* 17.3.5
*/
return jmsConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira