Thanks for your reply, Sean.

The example you linked to has a statement in the class comment that reads:
"This implementation is intended to be used on the web tier and not on the
ejb tier". This explains, perhaps, why there is no test for "java:comp/env"
in the JNDI name of the reference being looked up. However,
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servi
celocator/ejb/ServiceLocator.java.html (The EJB tier implementation) has no
such checking either.

I recognise that URLs, Strings and Booleans aren't cached, but this doesn't
solve the original problem - the "java:comp/env" namespace is bean-specific.
The same name may be used to refer to different objects in different beans,
so they cannot be cached.

Hence I see 2 conclusions:
- environment references should be explicitly excluded from any caching,
- I'm barking up the wrong tree.

I don't particularly like the second, so perhaps the first is the go.
However, the example doesn't cut it, so changing the implementation to
something like the generic method below may be the way to go.

public Object getObject(String jndiName)
  throws ServiceLocatorException {
Object obj = null;

try {
   if (cache.containsKey(jndiName)) {
      obj = cache.get(jndiName);
   } else {
      obj = ic.lookup(jndiName);

      // (untested!) don't cache local references
      if (!jndiName.startsWith("java:comp/env")) {
        cache.put(jndiName, obj);
      }
   }
} catch (NamingException ne) {
   throw new ServiceLocatorException(ne);
} catch (Exception e) {
   throw new ServiceLocatorException(e);
}

return obj;
}

The problem with this approach is that it almost removes the purpose for
caching in the EJB tier, particularly if extensive use is made of *-ref
entries (a good idea, AFAICS).

I'd be happy for someone to tell me that I'm up the creek here - if not,
though, is it possible for the examples to change? This is something of a
trap for the unwary.

Many thanks,
JT


-----Original Message-----
From: Sean Brydon [mailto:Sean.Brydon@(protected)]
Sent: Saturday, 15 November 2003 6:29
To: J2EEPATTERNS-INTEREST@(protected)

Hi,
You could take a look at a service locator example at J2EE BluePrints at
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servi
celocator/web/ServiceLocator.java.html
in which we use the caching mechanism for resources like EJB Homes etc
but dont cache the env entries.
hope that helps,
Sean

James Telfer wrote:

>Hello all,
>
>I am quite new to J2EE and have been using the ServiceLocator pattern based
>on the example code provided in the 2nd Edition. While I am aware that
>example code is just that, I would like to know if my problem is a bug in
>the example or a gap in my understanding.
>
>My question is whether JNDI references in the "java:comp/env" context
should
>be cached.
>
>As I understand it the env context is specific to each bean, allowing
>implementors to introduce a layer of abstraction between their hard-coded
>JNDI references and the deployment environment. If this is the case, my
>implementation should exclude local environment references.
>
>This would not be an issue if the Singleton pattern was not used, of
course,
>but neither would the caching be as effective. That said, if extensive use
>of the *-ref deployment descriptor elements is made, caching would be of
>very little value.
>
>Thanks for your help,
>James Telfer
>

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)