JNDI searches
in [Java Programming]
|
From: Tim Slattery on 8 Apr 2010 09:03 We run our JEE web apps in BEA (now Oracle) Weblogic. We've from time to time explored alternatives. Generally moving a WAR to another platform works fine, with one exception.... We have a JNDI data source defined in the container, say "myData". To use it, we make a call like: InitialContext ic = new InitialContext(); DataSource datasource = (DataSource) ic.lookup("myData"); In Weblogic this works just fine, and I can use the datasource to access the DB. But when we tried JBoss, I had to search for "java:/myData". And when I run the app in Tomcat, I have to use "java:/comp/env/jdbc/myData". So to move my app to another container, I have to recompile and remake the WAR. This seems completely nuts to me. Am I missing a way around this, or am I doomed to recompile and/or add searches on more and more variants of the JNDI name? -- Tim Slattery Slattery_T(a)bls.gov http://members.cox.net/slatteryt
From: Jean-Baptiste Nizet on 8 Apr 2010 12:33 Tim Slattery a �crit : > We run our JEE web apps in BEA (now Oracle) Weblogic. We've from time > to time explored alternatives. Generally moving a WAR to another > platform works fine, with one exception.... > > We have a JNDI data source defined in the container, say "myData". To > use it, we make a call like: > > InitialContext ic = new InitialContext(); > DataSource datasource = (DataSource) ic.lookup("myData"); > > In Weblogic this works just fine, and I can use the datasource to > access the DB. But when we tried JBoss, I had to search for > "java:/myData". And when I run the app in Tomcat, I have to use > "java:/comp/env/jdbc/myData". > > So to move my app to another container, I have to recompile and > remake the WAR. > > This seems completely nuts to me. Am I missing a way around this, or > am I doomed to recompile and/or add searches on more and more variants > of the JNDI name? > The standard way is to define a resource-ref in your web.xml file. By convention, resource-refs for JDBC datasources are defined in the jdbc context. For example : jdbc/myDataSource. All the resource-refs defined in we.xml are accessible via the java:comp/env/ context. In this case, you would thus have to use initialContext.lookup("java:comp/env/jdbc/EmployeeDB"). The name of the resource-ref is purely logical, and constitutes an indirection for the real name of the dataSource in the app server. this allows deploying two web-apps using a different logical name internally for their dataSource, but effectively sharing a common physical dataSource. Everything above is standard, and supported by every JEE appserver. The mapping between the logical name of the resource-ref and the physical dataSource is where the standard doesn't say anything. It depends on the appserver. In Tomcat, you have to declare a resource in the context of the webapp (see http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#JDBC%20Data%20Sources) In WebLogic, you have to declare the link between the logical name and the physical dataSource in the weblogic.xml proprietary descriptor. See http://download.oracle.com/docs/cd/E15523_01/web.1111/e13712/weblogic_xml.htm#i1087465 Hope it helps. JB.
From: Donkey Hottie on 8 Apr 2010 13:04 On 8.4.2010 16:03, Tim Slattery wrote: > We run our JEE web apps in BEA (now Oracle) Weblogic. We've from time > to time explored alternatives. Generally moving a WAR to another > platform works fine, with one exception.... > > We have a JNDI data source defined in the container, say "myData". To > use it, we make a call like: > > InitialContext ic = new InitialContext(); > DataSource datasource = (DataSource) ic.lookup("myData"); > > In Weblogic this works just fine, and I can use the datasource to > access the DB. But when we tried JBoss, I had to search for > "java:/myData". And when I run the app in Tomcat, I have to use > "java:/comp/env/jdbc/myData". > > So to move my app to another container, I have to recompile and > remake the WAR. > > This seems completely nuts to me. Am I missing a way around this, or > am I doomed to recompile and/or add searches on more and more variants > of the JNDI name? > Do this for JBoss in deploy/mysql-ds.xml or whatever defines the data source for server. <datasources> <local-tx-datasource> <jndi-name>jdbc/myData</jndi-name> <use-java-context>false</use-java-context> <connection-url>jdbc:mysql://dbsrv:3306/mydata</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> The "use-java-context" is the key. I don't know if this works for Tomcat, but as JBoss uses Tomcat it might. -- Consider well the proportions of things. It is better to be a young June-bug than an old bird of paradise. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
From: Tom Anderson on 8 Apr 2010 13:28 On Thu, 8 Apr 2010, Tim Slattery wrote: > We run our JEE web apps in BEA (now Oracle) Weblogic. We've from time > to time explored alternatives. Generally moving a WAR to another > platform works fine, with one exception.... > > We have a JNDI data source defined in the container, say "myData". To > use it, we make a call like: > > InitialContext ic = new InitialContext(); > DataSource datasource = (DataSource) ic.lookup("myData"); > > In Weblogic this works just fine, and I can use the datasource to > access the DB. But when we tried JBoss, I had to search for > "java:/myData". And when I run the app in Tomcat, I have to use > "java:/comp/env/jdbc/myData". The Tomcat form is what the standard specifies. If you use that in WebLogic and JBoss, does it work? It should. If so, you can use that across the board. If not, er, well, yes. Define a server-dependent JNDI name prefix and pass it in as an env-entry or system property, perhaps? tom -- unconstrained by any considerations of humanity or decency
From: Tim Slattery on 8 Apr 2010 16:13
Tom Anderson <twic(a)urchin.earth.li> wrote: >The Tomcat form is what the standard specifies. If you use that in >WebLogic and JBoss, does it work? Don't know about JBoss (that was a while ago), but it does not work in Weblogic. >If not, er, well, yes. Define a server-dependent JNDI name prefix and pass >it in as an env-entry or system property, perhaps? No idea of that. -- Tim Slattery Slattery_T(a)bls.gov http://members.cox.net/slatteryt |