[Messaging, JMS & JBossMQ] - Re: connectionFactoryJndiName config property
by tobinibot
THAT WORKED!!!
Thank you so much for your help, you have no idea how desperate we were getting.
If anyone else is still reading along, here is what my final MDB looks like:
package ejb;
|
| import javax.ejb.ActivationConfigProperty;
| import javax.ejb.MessageDriven;
| import javax.jms.Message;
| import javax.jms.MessageListener;
| import org.jboss.annotation.ejb.ResourceAdapter;
| import org.jboss.logging.Logger;
|
| /**
| * @author tjuday
| */
| @MessageDriven(mappedName = "jms/SimpleMessageReceiverBean", activationConfig = {
| @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
| @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
| @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue.outbound")
| })
| @ResourceAdapter("activemq-ra-4.0.2.rar")
| public class SimpleMessageReceiverBean implements MessageListener {
| private Logger logger = Logger.getLogger(SimpleMessageReceiverBean.class);
|
| public void onMessage(Message message) {
| logger.info("received message");
| }
| }
I've got a little more playing around to do, I would like to see if ActiveMQ will create a non-existent destination, or if it has to be bound. I'll report back my findings here.
Weston, again, thanks for your all you work. You've been a great help.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990179#3990179
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990179
18Â years, 1Â month
[JBoss Seam] - Re: Excessive [could not destroy component] 1.1B1 to 1.1CR1
by rdewell
Yes I see that thread. Using the XML descriptor is merely configuring that annotation, so they are functionally equivalent. The XML has the downside of not being granular enough to say that Session scoped SFSB should have a longer timeout than say a Conversation scoped SFSB.
You're up against Seam and JBoss notions of SFSB lifetimes, and AFAIK @CacheConfig is the ONLY way to handle this granularly.
I'm originally reported this SFSB timeout issue with Seam:
http://jira.jboss.org/jira/browse/JBSEAM-279
As is reported in that ticket, @CacheConfig used to solve this lifetime mismatch. I don't like the solution either, but there really was/is no other solution.
As of sometime between b1 and cr1, however, something has happened and @CacheConfig doesn't do the trick anymore. Actually, it's even worse than before that reported ticket.
On a related note, I'd really like to know how Seam is going to handle this problem across different JEE implementations. Could Seam "ping" the SFSB's it controls periodically so the container doesn't time them out?
OR, are you suggesting that in the XML configuration we should set the SFSB timeout to Integer.MAX_VALUE? Effectively telling JBoss to never expire SFSB beans? That just seems like it would very dangerous and put a lot of responsibility on Seam to cleanup unexpected problems with lingering SFSB's.
OR, if from Seam's standpoint this is a benign warning, could it do something else besides throw up a stack trace? Like:
"WARN: Seam could not destroy component XVB. This is probably safe to ignore, but may represent an SFSB timeout setting that is too low for the Seam scope."
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990176#3990176
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990176
18Â years, 1Â month