Posted By:
Kenneth_Wallis
Posted On:
Wednesday, August 20, 2003 02:11 PM
Both of your examples instantiate the InitialContext instance without passing the Properties argument. Therefore, in the strictest since both of your examples are in-fact identical. The second would behave exactly like the first if you executed it within a application which forced the system properties via command line arguments (-Djava.naming....)
Instead, you should create a Properties instance and pass it into the InitialContext to truly differentiate the 2 patterns.
Properties ctxProperties = new Properties();
ctxProperties.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
ctxProperties.put("java.naming.provider.url", "localhost:1099");
InitialContext context = new InitialContext(ctxProperties);
Ideally, this pattern would use a dynamic means of identifying the property values rather than hardcoded as I've shown.
That said; you would implement the 2nd approach (i.e., no properties specified) if you wanted to rely on the environment to provide the context definition. This might be valid either because the command arguments were enforcing it or because your component was executing within a container which provided viable defaults for it.
Conversely, you would implement the 1st approach (or my snippet) if your component needed to control the construction of the context. This might occur because the component is executing outside all other controlling environments (ex: client app) or because you needed to dictate a specific target for the context. For example: our product deploys components to both an application server and a standalone JNDI server; accessing the components requires separate contexts instantiated from different properties.
