[JBoss jBPM] - inject datasource into Action
by gogoasa
Hello,
I would like to have something like :
public class OnStartAction implements ActionHandler {
| Datasource datasource;
|
| ...
| }
And I would like to have the "datasource" property injected by jBPM. I haven't actually found a direct solution. What I can do at this point is to add this declaration to jbpm.cfg.xml :
<bean name="extra-datasource" class="javax.sql.Datasource" singleton="true">
| <constructor factory-class="fr.bnf.entrychain.jbpm.actions.helper.TestDatasourceFactory" method="lookupDatasource">
| </constructor>
| </bean>
... and have the following code inside the action :
ds = (DataSource) ctxt.getJbpmContext().getObjectFactory().createObject("extra-datasource");
I don't like this solution because it's not very DI-compliant. Some injection may be done by mocking the whole jbmcontext.objectfactory... object graph but I would kind of bet there's a simpler solution.
Thanks for any ideas.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064508#4064508
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064508
19Â years
[Messaging, JMS & JBossMQ] - Re: QueueDepth dropping to 0, Message Cache involved, NACK m
by adrianï¼ jboss.org
"syedtaj" wrote :
|
| 2007-07-15 20:34:10,968 34037115 TRACE [org.jboss.mq.server.BasicQueue] (UIL2(SocketManager.MsgPool@a425da client=10.0.10.76:1057)#44:) acknowledge AcknowledgementRequest:NACK,QUEUE.dispatchToNodeQueue,ID:80-11845305690466087 40564 org.jboss.mq.server.PersistentQueue(a)12da4a6{id=QUEUE.dispatchToNodeQ
| ueue}
|
A NACK is a negative acknowledgement. i.e. the client did not accept the message.
You can see it putting the message back in the queue for somebody else to process.
anonymous wrote :
| 2007-07-15 20:34:10,976 34037123 TRACE [org.jboss.mq.server.BasicQueue] (UIL2(SocketManager.MsgPool@a425da client=10.0.10.76:1057)#44:) Restoring message: 4911 msg=4523 hard STORED PERSISTENT queue=QUEUE.dispatchToNodeQueue priority=4 lateClone=false hashCode=16957640
|
anonymous wrote :
| At this point, the queue depth rises but drops steadily again.
|
That's the expected behaviour if you think about.
One client NACKs the message then another one receives it.
Why the client is not acknowledging the messages it is receiving
is something for you to determine.
The rest of your post is irrelevant to that question.
*GUESS 1": It's always rolling back because some process cannot complete.
*GUESS 2": You forgot to commit the session, so only when the session
is closed are the messages from the incomplete transaction NACKed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064505#4064505
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064505
19Â years