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=detail&atid=376685&aid=1081962&group_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=detail&atid=376685&aid=1081962&group_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
