Tomcat, Problem mit context.xml

[Niki]

Hallo Tomcat Experten!

Ich habe folgendes Problem. Ich liefer an unseren Betrieb ein war-File aus. In diesem war-File befindet sich unter META-INF eine context.xml mit der DataSource für die Datenbank. In der DataSource-Definition befindet sich nur das Template, d.h. es beinhaltet nur driver und url nicht jedoch user und pwd. Der Betrieb füllt dann diese Attribute noch aus bzw. überspielt die neue context.xml mit der richtigen.
Wenn das war-File deployt wird, wird anscheinend die context.xml ins conf/Catalina/localhost mit Dateinamen [webapp].xml kopiert. Diese xml-Datei dürfte jedoch vor der context.xml der WebApp gelesen werden und beinhaltet daher die leeren user/pwd Attribute. Der Fehler wird bereinigt wenn das war-File und diese [webapp].xml gelöscht werden. Das ist natürlich keine optimale Lösung, was könnte man da besser machen? Eventuell die context.xml in die server.xml einbinden, oder die context.xml gar nicht mehr ausliefern?

Danke für Tipps!

 

[maki]

Warum nicht auf Containermanaged ConnectionPool/DS umsteigen?

So würde der Kunde seinen TC konfigurieren und damit die Datasource nebst Usernnamen und Passwort, die Anwendung (in der context.xml) steht dann nur noch der JNDI Name der DS, welcher immer gleich bleiben kann.

 

[Niki]

Danke für die Antwort. Wo kann man das beim TC konfigurieren? In der server.xml? Muss ich dann überhaupt noch die context.xml ausliefern wenn in der server.xml eh schon die DataSource konfiguriert ist? Oder schaut das anders aus?

 

[maki]

In der Server XML wird die DS konfiguriert (Conatiner Managed), in der Context.xml steht dann nur drinnen, dass diese DS von der Anwendung genutzt wird.

Glaube mich erinnern zu können das da was mit "resource links" oder ähnlich war... werde mal schnell suchen.

Nachtrag 1:
Vielleicht hilft dir das:http://opensource.atlassian.com/confluence/oss/pages/viewpage.action?pageId=12582997

Geht zwar um iBatis und Tomcat JNDI DS, aber ignoriere die iBatis config, nimm die server.xml Config + context.xml config, dein Code muss einen JNDI Aufruf machen um die DS zu bekommen.

Nachtrag 2:
Die orig. TC Doku dazu:
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html

 

[Niki]

Die DataSource hol ich mir eh schon über JNDI:

		Context initContext = new InitialContext();
		DataSource dataSource = (DataSource) initContext
				.lookup("java:comp/env/jdbc/MyDataSource");
		Connection con = dataSource.getConnection();
		con.setAutoCommit(false);

passt so, oder?

Ich werd das mal so ausprobieren wie du gesagt hast. Das wäre sicher eine bessere Lösung.

 

[maki]

Sieht gut aus, allerdings glaube ich dass es da Unerschiede gab, ob man java:comp/env/jdbc/MyDataSource oder jdbc/MyDataSource verwendete, am besten beides mal probieren wenn es die JNDI DS nicht findet.

Kann dir auch lambda Probe empfehlen, da kann man die DS gleich ausprobieren, und vieles vieles mehr

 

[Niki]

Nach drei Wochen bin ich doch einmal endlich dazu gekommen das ganze nochmal anzuschauen. Es ist tatsächlich sehr einfach und zwar muss man in der conf/server.xml unter dem Tag GlobalNamingResources seine Resourcen definieren und in der META-INF/context.xml der WebApp einfach darauf verweisen:

<ResourceLink name="jdbc/MyDSName" global="jdbc/MyDSName" type="javax.sql.DataSource"/>

Das ist alles. In der WebApp ist sonst nichts zu ändern. Der Unterschied beim JDNI-Namen entsteht glaub ich dann, wenn man die DataSource direkt holt, oder zuerst den Context, beides ist möglich:

Context initContext = new InitialContext();
DataSource dataSource = (DataSource) initContext
				.lookup("java:comp/env/jdbc/MyJDBCDataSource");

oder

Context initContext = new InitialContext();
		
		Context context = (Context)initContext.lookup("java:comp/env");
		DataSource dataSource = (DataSource)context.lookup("jdbc/MyJDBCDataSource");

Ich hab beides getestet und beides funktioniert