Warum ClassCastException bei JMS ConnectionFactory-Suche in JNDI?

Question

Was könnte die folgende ClassCastException in einer eigenständigen JMS-Clientanwendung verursachen, wenn sie versucht, eine Verbindungsfactory vom JNDI-Anbieter abzurufen? Hier

Exception in thread "main" java.lang.ClassCastException: javax.naming.Reference cannot be cast to javax.jms.ConnectionFactory 

ist eine gekürzte Version des JMS-Client, der nur seine start() und stop() Methoden enthält. Die Ausnahme tritt in der ersten Zeile in der Methode start() auf, die versucht, die Verbindungsfactory vom JNDI-Provider, einem Remote-LDAP-Server, abzurufen. Die JMS-Verbindungsfactory und die Zielobjekte befinden sich auf einem Remote-JMS-Server.

class JmsClient { 
    private ConnectionFactory connectionFactory; 
    private Connection connection; 
    private Session session; 
    private MessageConsumer consumer; 
    private Topic topic; 

    public void stop() throws JMSException { 
     consumer.close(); 
     session.close(); 
     connection.close(); 
    } 

    public void start(Context context, String connectionFactoryName, String topicName) throws NamingException, JMSException { 
     // ClassCastException occurs when retrieving connection factory. 
     connectionFactory = (ConnectionFactory) context.lookup(connectionFactoryName); 
     connection = connectionFactory.createConnection("username","password"); 
     session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 
     topic = (Topic) context.lookup(topicName); 
     consumer = session.createConsumer(topic); 
     connection.start(); 
    } 

    private static Context getInitialContext() throws NamingException, IOException { 
     String filename = "context.properties"; 
     Properties props = new Properties(); 
     props.load(new FileInputStream(filename)); 
     return new InitialContext(props); 
    } 
} 

Obwohl ich es vorziehen, nicht die spezifischen Inhalte von context.properties offen zu legen, es enthält die folgenden allgemeinen Angaben:

java.naming.factory.initial=... 
java.naming.provider.url=... 
java.naming.security.principal=... 
java.naming.security.credentials=... 

Answer 1

Es stellte sich heraus, dass das Problem auf eine Tibco JMS jarfile zurückzuführen war, tibjms.jar, abwesend aus dem JVM-Klassenpfad. Diese JAR-Datei implementiert das Tibco JMS-Protokoll, und deshalb konnte der JMS-Client die JMS-Verbindungsfactory nicht vom LDAP-JNDI-Dienstanbieter abrufen, da sie fehlte.