JMS ohne JNDI?

Question

Wir führen Portlets in WebSphere 6.01 mit Java 1.4 aus. Wir möchten JMS-Nachrichten an eine JBoss 5-Warteschlange senden, auf der Java 5 ausgeführt wird (oder vielleicht 6, aber es ist sicherlich neuer als 1.4). Der Versuch, eine Verbindung mithilfe von JNDI herzustellen, funktioniert nicht, da wir die JBoss-Client-JAR-Dateien in den Klassenpfad des Portlets aufnehmen müssen und sie sind Java 1.5. Daher erhalte ich einen nicht unterstützten Major/Minor-Fehler, wenn ich versuche, den InitialContext zu erstellen.

Können wir direkt mit JBoss verbinden, ohne JNDI zu verwenden? Oder gibt es einen Weg, um dieses Problem zu umgehen, an das ich nicht denken kann?

Answer 1

Auch wenn Sie eine Verbindung zu JMS herstellen konnten, ohne den JNDI von JBoss zu durchlaufen, müssten Sie dennoch die JBoss-Client-JAR einbeziehen, um JMS zu verwenden. Sowohl JNDI als auch JMS sind APIs, und Sie benötigen die Server-Implementierung dieser Client-API, um mit dem Server zu kommunizieren.

Answer 2

Ich denke, JNDI ist die einzige Möglichkeit, JMS-Verbindungsfabriken und -ziele (Warteschlange oder Thema) zu erstellen, und dies sind Ihre Kommunikationsmittel.

Answer 3

Je nach JBoss-Version können Sie alle JMS-Objekte direkt instanziieren.

Eine besondere Version: sehen http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/using-jms.html

(Abschnitt 5.5 Direkt JMS Ressourcen Instanziieren ohne JNDI zu verwenden.)

Answer 4

In der Tat JNDI ist ein Weg, unabhängig von der JMS-Provider zu sein, weil Sie easly können ändern Sie es. Aber wenn Sie kein Problem damit haben die meisten Provider bieten Einrichtungen zum Erstellen einer Verbindung Fabrik und Destinationen

Answer 5

Wenn es nur Ihre JNDI-Klassen, die Java 5 und nicht die JBoss-Klassen Voraussetzung, dann können Sie dies tun. Sie müssten jedoch alle Eigenschaften der Objekte festlegen, und das ist Provider-spezifisch. Die WebSphere MQ-JMS-Beispiele zeigen, wie dies mit WMQ durchgeführt wird, und Sie müssen die Eigenschafts- und Wertnamen für JBoss kennen, um den entsprechenden Code zu erstellen. Hier ist ein Code-Schnipsel aus dem WMQ JmsProducer.java Beispiel:

JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER); 
    JmsConnectionFactory cf = ff.createConnectionFactory(); 

    // Set the properties 
    cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host); 
    cf.setIntProperty(WMQConstants.WMQ_PORT, port); 
    cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel); 
    cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT); 
    cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName); 

    // Create JMS objects 
    connection = cf.createConnection(); 
    session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); 
    if (isTopic) { 
    destination = session.createTopic(destinationName); 
    } 
    else { 
    destination = session.createQueue(destinationName); 
    } 
    producer = session.createProducer(destination); 

Auf der anderen Seite, wenn Ihre JBoss Klassen PreReq Java 1.5, dann müssen Sie Java 1.5 oder besser ausgeführt werden.

Answer 6

Es klingt wie das Problem ist nicht mit JNDI, sondern mit den in Konflikt stehenden Klassennamen zwischen den Umgebungen.

Sie könnten versuchen, das Classloading durchzuführen, wenn Sie versuchen, die JBOSS-Clientklassen zu instanziieren. Auf diese Weise erhalten Sie einen separaten Klassenlader von dem, der das Portlet geladen hat. Stellen Sie sicher, dass Sie verstehen, ob Sie Parent-first or Parent-last behavior benötigen. Auf dieser Seite befindet sich auch debugging classloading, die Ihnen zeigen kann, wie Sie den Klassenpfad für den Klassenlader festlegen, damit Sie die JBOSS-Bibliotheken isolieren und Klassenkonflikte vermeiden können. Es ist eine gute Quelle für das Verständnis selbst advanced classloading issues.