Kenneth Saks wrote:
>
> 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?
You are absolutely right. The code was incomplete; I just wanted to
convey the idea. The actual code will look something like the attached
file, where environment is used to see if user wants us to use a
different InitialConbtextFactory class. If yes, we use Thread's context
class loader to load it and instantiate the same.
Thanks,
Sahoo