dev@glassfish.java.net

Re: [GFv3] Locating InitialContextFactory without using jndi-properties.jar

From: Kenneth Saks <Kenneth.Saks_at_Sun.COM>
Date: Wed, 27 May 2009 16:55:15 -0400

On May 26, 2009, at 4:40 PM, Sahoo wrote:

> Jerome, Mahesh, Ken S.,
>
> Currently, we have jndi-properties.jar in glassfish/lib. The jar
> file contains a single resource called jndi.properties file which
> has the following entry in it:
>
> java
> .naming
> .factory
> .initial=com.sun.enterprise.naming.impl.SerialInitContextFactory
>
> Since this jar file is visible to all J2EE apps, when they do new
> InitialContext(), the appropriate initial context factory is used by
> naming module (we actually use JDK's naming module). The problem
> comes when an application can't see lib/jndi.properties file. e.g.,
> when an OSGi bundle does new InitialContext().

> So, I suggest we do something like this to avoid dependency on lib
> dir:
>
> @Service
> public class GlassFishNamingBuilder implements
> javax.naming.spi.InitialContextFactoryBuilder,
> org,glassfish.api.Startup, org.jvnet.hk2.component.PostConstruct {
> public InitialContextFactory
> createInitialContextFactory(Hashtable<?,?> environment) {
> return new
> com.sun.enterprise.naming.impl.SerialInitContextFactory();
> }

This will work in the case that the caller actually wants our default
no-arg InitialContext, but what if they're trying to explicitly
instantiate some other InitialContext?

> public void postConstruct() {
> setInitialContextFactoryBuilder(this); // TODO: add appropriate
> doPrivileged() here
> }
> }
>
> I have not tried this yet. What do you think?



>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>