try (
Context ctx = (Context) new InitialContext (). Lookup ( "java: comp / env");
ds = (DataSource) ctx.lookup ( "jdbc / test");
conn = this.getConn ();
) catch (Exception e) (
System.out.println (e.toString ());
)
Access to data sources on the syntax, there is general (javax.sql.DataSource) ctx.lookup ( "java: comp / env / XXX") and (javax.sql.DataSource) ctx.lookup ( "XXX") The two ways for writing, Many people think that the wording of these two are the same, that is to get through the JNDI data source. In fact, java: comp / env and JNDI are different, java: comp / env environment naming context (environment naming context (ENC)), is 1.1 in the EJB specification introduced after the introduction of the original order to solve this is caused by JNDI to find conflict, but also to improve the EJB or J2EE application portability. ENC is a quote, quote for the positioning of the enterprise applications of the logic of external resources. Quoted in the application deployment descriptor definition file. In the deployment, the references are bound to the target operational environment, the physical location of resources (JNDI name). ENC is the use of other resources for the hard-coded JNDI to find out, through the configuration of the reference can not amend the code, people will point to different EJB (JNDI). In J2EE used in reference are:
--------- JDBC data sources cited in the java: comp / env / jdbc stated subcontext
--------- JMS connection factories in the java: comp / env / jms stated subcontext
--------- JavaMail connection factories in the java: comp / env / mail stated subcontext
--------- URL connection factories in the java: comp / env / url stated subcontext
If you write an EJB, such as the datasource to obtain: dataSource = (DataSource) ctx.lookup ( "java: comp / env / jdbc / DBPool");
Well, in the configuration file for resource mapping, in the ejb-jar.xml, the
<resource-ref>
<res-ref-name> jdbc / DBPool </ res-ref-name>
<res-type> javax.sql.DataSource </ res-type>
<res-auth> Container </ res-auth>
</ resource-ref>
In weblogic-ejb-jar.xml, the
<reference-descriptor>
<resource-description>
<res-ref-name> jdbc / DBPool </ res-ref-name>
<jndi-name> OraDataSource </ jndi-name>
</ resource-description>
</ reference-descriptor>
/ / To those Note: If it is in the jboss done in the following modifications jboss.xml
<resource-managers>
<resource-manager>
<res-name> jdbc / DBPool </ res-name>
<res-jndi-name> OraDataSource </ res-jndi-name>
</ resource-manager>
</ resource-managers>
JNDI actual server name is OraDataSource, the logical name jdbc / DBPool and it is only used for mapping, the benefits of doing so is to improve the portability, time to transplant only to change the configuration file can be, and applications there is no need for change.
If you write a general application, would like to get directly through the JNDI data source, then the direct lookup ( "mytest") will be a (if the JNDI server for mytest), written with the first error instead of .
java: comp / env is the standard J2EE environment to use this method to find the rules of an environment must be done to the JNDI name of the mapping that makes the isolation procedures do not have to write a real concern about the fact that the JNDI name with the white on the configuration of the JNDI document is the same as the usage is as follows, if the java: comp / env / my / datasource mapped to my.ora.dataource
web.xml
<resource-ref> <BR>
<res-ref-name> my / datasource </ res-ref-name> <BR>
<res-type> javax.sql.DataSource </ res-type> <BR>
<res-auth> CONTAINER <res-auth> <BR>
</ resource-ref>
<resource-ref>
<res-ref-name> my / datasource </ res-ref-name>
<res-type> javax.sql.DataSource </ res-type>
<res-auth> CONTAINER <res-auth>
</ resource-ref>
weblogic.xml
<reference-descriptor> <BR>
<resource-description> <BR>
<res-ref-name> my / datasource </ res-ref-name> <BR>
<jndi-name> my.ora.dataource </ jndi-name> <BR>
......
<reference-descriptor>
<resource-description>
<res-ref-name> my / datasource </ res-ref-name>
<jndi-name> my.ora.dataource </ jndi-name>
......
Without the use of the prefix is actually a direct JNDI name
-------------------------
Not add to the overall situation when the JNDI name, this will result in the application of the coupling between the EJB is too high, does not recommend the use of
Context ctx = (Context) new InitialContext (). Lookup ( "java: comp / env");
ds = (DataSource) ctx.lookup ( "jdbc / test");
conn = this.getConn ();
) catch (Exception e) (
System.out.println (e.toString ());
)
Access to data sources on the syntax, there is general (javax.sql.DataSource) ctx.lookup ( "java: comp / env / XXX") and (javax.sql.DataSource) ctx.lookup ( "XXX") The two ways for writing, Many people think that the wording of these two are the same, that is to get through the JNDI data source. In fact, java: comp / env and JNDI are different, java: comp / env environment naming context (environment naming context (ENC)), is 1.1 in the EJB specification introduced after the introduction of the original order to solve this is caused by JNDI to find conflict, but also to improve the EJB or J2EE application portability. ENC is a quote, quote for the positioning of the enterprise applications of the logic of external resources. Quoted in the application deployment descriptor definition file. In the deployment, the references are bound to the target operational environment, the physical location of resources (JNDI name). ENC is the use of other resources for the hard-coded JNDI to find out, through the configuration of the reference can not amend the code, people will point to different EJB (JNDI). In J2EE used in reference are:
--------- JDBC data sources cited in the java: comp / env / jdbc stated subcontext
--------- JMS connection factories in the java: comp / env / jms stated subcontext
--------- JavaMail connection factories in the java: comp / env / mail stated subcontext
--------- URL connection factories in the java: comp / env / url stated subcontext
If you write an EJB, such as the datasource to obtain: dataSource = (DataSource) ctx.lookup ( "java: comp / env / jdbc / DBPool");
Well, in the configuration file for resource mapping, in the ejb-jar.xml, the
<resource-ref>
<res-ref-name> jdbc / DBPool </ res-ref-name>
<res-type> javax.sql.DataSource </ res-type>
<res-auth> Container </ res-auth>
</ resource-ref>
In weblogic-ejb-jar.xml, the
<reference-descriptor>
<resource-description>
<res-ref-name> jdbc / DBPool </ res-ref-name>
<jndi-name> OraDataSource </ jndi-name>
</ resource-description>
</ reference-descriptor>
/ / To those Note: If it is in the jboss done in the following modifications jboss.xml
<resource-managers>
<resource-manager>
<res-name> jdbc / DBPool </ res-name>
<res-jndi-name> OraDataSource </ res-jndi-name>
</ resource-manager>
</ resource-managers>
JNDI actual server name is OraDataSource, the logical name jdbc / DBPool and it is only used for mapping, the benefits of doing so is to improve the portability, time to transplant only to change the configuration file can be, and applications there is no need for change.
If you write a general application, would like to get directly through the JNDI data source, then the direct lookup ( "mytest") will be a (if the JNDI server for mytest), written with the first error instead of .
java: comp / env is the standard J2EE environment to use this method to find the rules of an environment must be done to the JNDI name of the mapping that makes the isolation procedures do not have to write a real concern about the fact that the JNDI name with the white on the configuration of the JNDI document is the same as the usage is as follows, if the java: comp / env / my / datasource mapped to my.ora.dataource
web.xml
<resource-ref> <BR>
<res-ref-name> my / datasource </ res-ref-name> <BR>
<res-type> javax.sql.DataSource </ res-type> <BR>
<res-auth> CONTAINER <res-auth> <BR>
</ resource-ref>
<resource-ref>
<res-ref-name> my / datasource </ res-ref-name>
<res-type> javax.sql.DataSource </ res-type>
<res-auth> CONTAINER <res-auth>
</ resource-ref>
weblogic.xml
<reference-descriptor> <BR>
<resource-description> <BR>
<res-ref-name> my / datasource </ res-ref-name> <BR>
<jndi-name> my.ora.dataource </ jndi-name> <BR>
......
<reference-descriptor>
<resource-description>
<res-ref-name> my / datasource </ res-ref-name>
<jndi-name> my.ora.dataource </ jndi-name>
......
Without the use of the prefix is actually a direct JNDI name
-------------------------
Not add to the overall situation when the JNDI name, this will result in the application of the coupling between the EJB is too high, does not recommend the use of
Responses to “On the java: comp / env”