Bugs item #1081962, was opened at 2004-12-09 09:48
Message generated for change (Comment added) made by ejort
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=1081962group_id=22866
Category: JBossMQ
Group: v4.0
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Liran Zelkha (vzilka)
Assigned to: Nobody/Anonymous (nobody)
Summary: JBoss JMS Integration with 3rd parties
Initial Comment:
This is also relevant for 3.2.
While connecting external JMS provider to JBoss, using
the jms-ds.xml file, JBoss attempts to cast the
destination into the SpyDestination class. Of course,
other implementations' destinations do not extend the
SpyDestination class, and so a ClassCastException is
created.
The patchs for OracleAQ and MQSeries prove that this
bug has existed for quite some time.
However, the SpyDestination class has almost only
static methods, so the inheritance model is probably
incorrect. It should use an inheritance + aggregation
model to hold other destination types as well.
--
Comment By: Adrian Brock (ejort)
Date: 2004-12-13 23:00
Message:
Logged In: YES
user_id=9459
Neither the server module (for the MDB) or the connector
module (for the
resource adapter) reference JBossMQ classes.
They are both JMS vendor neutral.
This is easily seen by looking at the builds for these
module which
do not include JBossMQ in the classpath.
Hence they cannot possibly be doing a cast to SpyDestination.
There are a couple of instances where JBossMQ behaviour
is done in the MDB, but neither require the JBossMQ classes.
The only way I can think of to get this behaviour (you haven't
posted the stacktrace so I have to guess) is that you are
trying to talk to a third party vendor topic via a JBossMQ
ConnectionFactory. Something that is bound to fail.
This would mean you haven't configured jndi correctly.
The only reason for the WSMQ patch is because the
connection factories need special configuration that
nobody has figured out how to do using JNDI federation
(include WSMQ JNDI in JBoss JNDI).
I imagine the Oracle version is the same, I have never tried it
myself?
I see no need for either patch if JBoss accesses these
admin objects via external jndi configuration/federation.
Even if it just serialized the object to disk and used
used Sun's FSContext.
But then people find the JMX config provided by those patches
easier to understand than federating JNDI.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=1081962group_id=22866
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
