Tomcat vs Jetty JNDI Lookup

Ich verwende Spring mein Java-Webanwendung konfigurieren und in meiner Spring-Konfiguration I eine Datenquelle über JNDI für Jetty erhalten wie folgt:Tomcat vs Jetty JNDI Lookup

<jee:jndi-lookup id="dataSource" jndi-name="jdbc/myDataSource" />

aber dies wird mit Tomcat nicht funktionieren . Mit Tomcat habe ich dies zu tun:

<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/myDataSource" />

Was ist der beste Weg, dies zu lösen? Ich verwende bereits JNDI als Möglichkeit, die Konfiguration extern zu machen, sodass ich meine externalisierte Konfiguration nicht externalisieren kann! Gleichzeitig verabscheue ich die Idee, zwei separate Spring-Konfigurationsdateien zu haben. HILFE!!!

Quelle

2010-11-30 HDave

ich eine Antwort here gefunden, aber ich dachte, dass es ein wenig kompliziert, aber es gab mir die Idee, die sehr zu verwenden cool ServerDetector Klasse dieser Blogger hatte gefunden.

Sobald ich dynamisch herausfinden kann, welche Art von Server, in der ich laufen, konnte ich den Frühling Ausdruck Sprache verwenden, um den Rest der Arbeit zu tun:

<jee:jndi-lookup id="myAppDataSource" 
    jndi-name="#{ (AppServerType == 'Jetty' ? 'jdbc/' : 'java:comp/env/jdbc/') + 
        'myAppDataSource' }" />

Easy!

Quelle

2010-12-15 15:43:29 HDave

Der sauberste Weg ist es, Ihre Konfiguration zu konfigurieren. ;)

Verwenden Sie einen Platzhalter für Federeigenschaften. Siehe

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-placeholderconfigurer

Die Grundidee ist, dass Sie nur mit einer Eigenschaft einen Platzhalter in Ihrem Frühjahr Config setzen, und dann liest sie passende Eigenschaft aus einem Properties-Datei. Sie generieren die Eigenschaftendatei in Ihrem Build-Prozess. Ich habe es gesehen, wo das Build-Tool (ant) eine Umgebungsvariable liest und dann basierend auf einer mit Tokens aufgefüllten Skelettdatei eine für die Umgebung geeignete Eigenschaftendatei erstellt.

Quelle

2010-11-30 03:14:22 hvgotcodes

Wollen Sie diesen Wert aus dem Platzhalter der Eigenschaft als jndi-name verwenden? Oder JNDI ganz zu überspringen? – HDave

@hdave, konfigurieren Sie jndi-name zu be = "{jndi.name}", wobei jndi.name eine Eigenschaft in einer Builddatei ist, die von Ihrem Erstellungsprozess generiert wird. Scheint du hast das Problem gelöst, aber diese Technik wird dir definitiv nützlich sein. – hvgotcodes

Ich denke, es wird so sein, dass ich mich bald der Unterstützung von Websphere nähern werde und ich verstehe, dass es einen eigenen funkigen Ansatz für JNDI-Pfade hat. – HDave

Nach ein paar Experimenten habe ich herausgefunden, dass ich Jetty zwingen könnte, denselben JNDI-Pfad wie Tomcat zu verwenden. Der folgende Ausschnitt ist aus meiner jetty-env.xml Datei:

<New id="myDataSource" class="org.mortbay.jetty.plus.naming.Resource"> 
    <!-- We MUST specify the entire JNDI path here to force compliance with the Tomcat/J2EE convention --> 
    <Arg>java:comp/env/jdbc/myDataSource</Arg> 
    <Arg> 
    <New class="com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean"> 
    <Set name="uniqueResourceName">sbeDatabase</Set> 
       ............... 
    </New> 
    </Arg> 
</New>

nicht sicher, ob dies ist ideal, aber es funktioniert.

aktualisieren:

Es funktioniert, wenn Sie Ihre Anlegestelle-env.xml Datei im WAR setzen ... aber aus irgendeinem Grund, die Sie diese Konfiguration außerhalb des WAR bewegen und in eine Datei Kontext Fragment in Jetty des „Kontext“ Verzeichnis dann wirft es eine Ausnahme:

Check it out: http://jira.codehaus.org/browse/JETTY-273

Quelle

2010-11-30 06:52:10 HDave

Ich mag das, weil es sich nicht auf den Xml-Krebs verlässt, den Spring ist. –

Tomcat vs Jetty JNDI Lookup

Antwort

Verwandte Themen