[Design of JBossCache] - Re: Channel creation - mux vs. old style
by bstansberry@jboss.com
A little more on why I don't want to support JMX lookup of the JChannelFactory -- besides the fact that in an IOC world, writing lookup code seems bogus.
Doing a JMX lookup presupposes that the MBeanServer is available before the call to Cache.create(). Otherwise, you can't do the lookup. In an AS 3.2.x or 4.x environment, that was a safe assumption, as that's the way the ServiceController worked. But if someone had created their cache programatically, it might have broken. That is, they could instantiate their cache, call startService() and then register it in JMX.
In 2.0, the coupling between the JMX wrapper and the Cache lifecycle is weaker. There's no strong reason to assume JMX registration will occur before create(). Adding logic to CacheJmxWrapper so it can deal with a situation where create is called first just adds complexity.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039676#4039676
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039676
18 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by timfox
"weston.price(a)jboss.com" wrote : This would be an unusual case as most JMS providers provide both a non XA and an optional XA CF to create the underlying connection.
|
| JBM would be the only JMS provider I have seen to date where you could not deploy a non XA JMS resource. WebSphereMQ, TIBCO, ActiveMQ, JBossMQ etc provide XA as an option as this is the only behavior mandated by the spec where the XA is optional.
|
|
Well, yes I agree this may be unusual, although I don't believe it it illegal.
It seems to me the JCA is making an incorrect assumption that a particular connection instance can't be both a Connection and an XAConnection. It just so happens up to now JBM is the only provider that implements it this way.
Having said all that, to get this fixed quickly, it should be fairly trivial for us to make the change in JBM to separate out the Connection and XAConnection classes. So I suggest we do that.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039605#4039605
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039605
18 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by weston.price@jboss.com
This would be an unusual case as most JMS providers provide both a non XA and an optional XA CF to create the underlying connection. What I am reading is that JBM does not provide the former as a standalone CF option.
The problem is that on the JCA side of things there is no way to determine from the 'transacted' parameter whether or not XA or non XA is to be used being that with XA this flag is simply ignored. In other words, the value of that flag is irrelevant in detrmining what type of connection to use (XA or non XA) being that there is not enough contextual information to make that determination. The only way to really do this would be to add a 'useXA' or 'isXA' type flag to the adapter that when present, would completely override the instanceof check to determine if it's XA or not. I am reluctant to do this as this as this would be the only case with a JMS provider where it it is necessary.
JBM would be the only JMS provider I have seen to date where you could not deploy a non XA JMS resource. WebSphereMQ, TIBCO, ActiveMQ, JBossMQ etc provide XA as an option as this is the only behavior mandated by the spec where the XA is optional.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039469#4039469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4039469
18 years, 11 months