Direct JNDI lookup warnings

I was browsing through the fix list for Version 6.1 of the Application Server and was interested to note that APAR PK32169 is removing the J2CA0294W warning messaging (unless you have debug trace turned on) in Fix Pack 5. This is the warning that you see when performing a direct JNDI lookup of a connection factory i.e. you go straight to the global namespace rather than using a resource-reference and the application’s local namespace (java:comp/env). This message has always been rather contentious as it asserted that direct JNDI lookups were being deprecated yet various parts of the product still continued to use them. There was even a technote describing how to suppress the warnings as, in some cases, they were causing significant performance degradation.

While it’s nice to see clarification that this functionality is not to be deprecated, it is worth pointing out what you are missing by not using resource-references. First, and most obviously, you are missing out on a layer of indirection, hardcoding in your application the name of an administratively defined resource. This leads to the possibility of naming collisions between different applications running in the same cell. However, as the warning message was always at pains to point out, without a resource-reference you are also getting the default settings for various properties.

One of these properties is the resource-authentication or res-auth which defaults to Application. This means that, in a secure environment, you have to either specify the connection credentials programmatically on creation or via a component managed authentication alias on the connection factory. Neither of these options is particularly good practice. The first means that the program has to hold the credentials somewhere and the second means that any server-side application with access to the JNDI namespace can create connections. Much better to use a resource-reference, specify a res-auth of Container, and then place the alias in the application bindings so it’s only available to the application that you intended.

5 Responses to “Direct JNDI lookup warnings”

  1. John Halada says:

    I am working with Rational Application Developer 7.0.

    I would like to do as you suggest, but RAD 7.0 has no spot where I can create such a resource reference. I have declared the Datasource as JNDI name “jdbc/ourds” in the Deployment tab of the Application Deployment Descriptor. Within the BMP and Session EJBs, I still have to call the lookup for “jdbc/ourds”. At runtime, this action generates plenty of warning messages.

    Is there a way to specify an alias as you describe within the facilities of RAD 7.0?

  2. Dave says:

    John – I haven’t installed RAD 7 yet as it doesn’t shell share with WebSphere Integration Developer which is the environment in which I spend most of my development time but I doubt it has changed much. Open the relevant deployment descriptor. Select the References tab, select the component which is accessing the resource and then hit Add. Select the radio button for Resource reference and click Next. Enter the name (e.g. jdbc/myds), the appropriate type (javax.sql.DataSource in your case) and set Authentication to Container, then click Finish. Then, in the WebSphere Bindings section, set the JNDI name to match the actual resource name (jdbc/ourds in your case). Select Use default method for the JAAS Login Configuration and enter your Authentication Alias (e.g. MyAuth). Then, all that remains is to define MyAuth via wsadmin and change the component to use the resource reference (i.e. a lookup of java:comp/env/jdbc/myds rather than jdbc/ourds).

  3. John Halada says:

    Thank you. It works as you said.

    I initially had problems because under RAD 7, the EJB Deployment Descriptor editor does not show the WebSphere Bindings section, initially. To get the bindings section to display, I had to edit the EJB Project’s Properties, and Add a “Project Facet” called “WebSphere EJB (Extended)”. Then the WebSphere Bindings appeared within the EJB Deployment Descriptor editor.

    I completed the bindings for my references and that cleared up the superfluous warning messages. Thanks again.

  4. Dave says:

    Ah yes – the dilemma of progressive disclosure. If it isn’t there, how do I know that I want to disclose it? I haven’t had to get to grips with facets yet although they do also appear in the Version 6.1 Application Server Toolkit. Thanks for posting back.

  5. Simon says:

    The Bindings section will also show if you add the facet Websphere Web (Co-Existence).