What steps are performed in the search? what does the first web.xml or context.xml look like?

Question

What the search looks like:

Context envContext = (Context)initContext.lookup("java:comp/env"); DataSource ds = (DataSource)envContext.lookup("jdbc/MyDatasource"); 

proceed?

I want to say what the search for MyDataSource looks like and, in the end, what returns?

Two entries are added to connect to the database. One of WEB-INF/web.xml , which:

 <resource-ref> <description>my connection</description> <res-ref-name>jdbc/MyDatasource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> 

and the other is added to META-INF/context.xml , which:

 <Resource name="jdbc/MyDatasource" auth="Container" type="javax.sql.DataSource" driverClassName="org.apache.derby.jdbc.ClientDriver" url="jdbc:derby://localhost:1527/My Database;create=true" username="me" password="me" maxActive="20" maxIdle="10" maxWait="-1" /> 

How do these 2 entries help in the search?

What looks first: web.xml or context.xml ?

Please explain the whole process in the search.

Answer 1

Resources are arranged in this order: web.xml (via <resource-ref> elements, context.xml , server.xml (via <GlobalNamingResources> ). Note that the resource defined in your <Context> is not really needed have corresponding <resource-ref> elements in your web.xml . See Tomcat documentation for JNDI resources: http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html

Answer 2

The following are the search steps:
STEP 1:

  Context context = new InitialContext(): 

The source context is a reference to the JNDI search service. This is similar to writing to the JNDI virtual directory tree.

STEP 2:

 Object o = context.lookup("mejb"): 

Here in the search we need to specify the name of the bean of what was deployed on the server to get a link to the home interface of this bean. Then we get an object of type java.lang.Object we need to pass this object to the main interface of any bean that we looked at.

STEP 3:

 Home home = (Home) PortableRemoteObject.narrow(o,Home.class): 

We really need to pass the object to a type, which, in our opinion, is a type. However, since this is RMI via IIOP, it seems to us that we need to use the PortableRemoteObject.narrow method, this, apparently, filters the type of the object to the actual type of the object and checks for errors.