Ich muss einen JNDI-Provider ohne den Overhead eines J2EE-Containers ausführen. Ich habe versucht, den Anweisungen in diesem article zu folgen, der (auf Seite 3) genau beschreibt, was ich tun möchte. Leider scheitern diese Richtungen. Ich musste das jboss-common.jar auch meinem Klassenpfad hinzufügen. Sobald ich das täte, bekomme ich einen Stack-Trace:JNDI ohne J2EE Container (mit JNP? Vielleicht ein anderer Anbieter?)
$ java org.jnp.server.Main
0 [main] DEBUG
org.jboss.naming.Naming - Creating
NamingServer stub, theServer=null,rmiPort=0,clientSocketFactory=null,[email protected]d093076[bindAddress=null]
Exception in thread "main"
java.lang.NullPointerException
at org.jnp.server.Main.getNamingInstance(Main.java:301)
at org.jnp.server.Main.initJnpInvoker(Main.java:354)
at org.jnp.server.Main.start(Main.java:316)
at org.jnp.server.Main.main(Main.java:104)
Ich hoffe, diese Arbeit zu machen, aber ich würde auch zu einem anderen leichten Standalone-JNDI-Provider offen. All dies soll ActiveMQ zum Laufen bringen, und wenn jemand einen anderen leichten JMS-Provider vorschlagen kann, der außerhalb der VM gut funktioniert, sind die Clients ohne einen voll funktionsfähigen App-Server, der auch funktioniert.
Dies scheint nicht die Tatsache abzudecken, dass wir einen TCP JNDI-Provider benötigen. Sofern ich mich nicht irre, funktionieren VM-Endpunkte nicht über VMs hinweg. Ich muss in der Lage sein, getrennte Prozesse zu führen, die über JNDI sprechen. Ist das mit diesem JNDI-Anbieter möglich? – Benson
Entschuldigung - ausschneiden und einfügen Problem. Ich habe gerade den * java.naming.provider.url * -Eintrag aktualisiert, so dass TCP verwendet wird - und Failover verwendet, den Sie standardmäßig verwenden sollten, um die Verbindung wiederherzustellen, wenn ein Socket fehlschlägt oder ein Broker geblockt wird –
Toll, danke. Ich muss das ausprobieren und sehen, ob es für mich funktioniert. – Benson