FakeInitialContext and java:/ root names

[kabirkhan]

I've modified the FakeInitialContext stuff so that you can now bind things to names like: java:/ConnectionFactory

What was needed was an InitialContextFactoryBuilder to make sure that the FakeInitialContext gets used rather than the "normal" InitialContext.

The way you set up things in the FakeInitialContext has changed from:

HashMap bindings = new HashMap();
 bindings.put("somename", myobj);
 bindings.put("othername", myobj2);
 FakeInitialContext.setBindings(bindings);

to:

InitialContext ctx = new InitialContext();//The jndi.properties file + ICFBuilder makes sure the FakeInitialContext gets used
 ctx.bind("somename", myobj);
 ctx.bind("othername", myobj2);

If you use the first method (calling FakeInitialContext directly), you end up with two versions of the static bindings HashMap contained in FakeInitialContext in some cases for some bizarre reason. This happened in TestCmdSTARTTLS.

So far FakeInitialContext overrides the lookup(), bind(), rebind() and getDefaultInitialCtx() methods inherited from InitialContext(), there are a few others that might need overriding down the line if we run into any more problems.

Cheers,

Kab

[kabirkhan]

Hi,

I'm having a slight problem with the jndi stuff for the testing. I am trying to use the jboss naming service rather than the fake contet stuff.

I have set up the jndi.properties file to be:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Next I stepped through the org.jboss.naming.NamingService.startService() method. The first bit loads up the properties from the jndi.properties file and sets the in System.properties, as expected there is no java.naming.provider.url there. Also, when I do a System.getProperty("java.naming.provider.url") at any stage nothing is returned.

However, once the first InitialContext is created and it's environment got, java.naming.provider.url is there! (i.e. it is in env below)

 InitialContext iniCtx = new InitialContext();
 Hashtable env = iniCtx.getEnvironment();

I followed this through, and new InitialContext()
calls javax.naming.InitialContext.init() //This initialises the environment for the InitialContext
which calls javax.naming.internal.ResourceManager.getInitialEnvironment()
which calls javax.naming.internal.VersionHelper.getJndiProperties()

VersionHelper.getProperties() looks like this

 String[] getJndiProperties() {
 if (getSystemPropsFailed) {
 return null; // after one failure, don't bother trying again
 }
 Properties sysProps = (Properties) AccessController.doPrivileged(
 new PrivilegedAction() {
 public Object run() {
 try {
 return System.getProperties();
 } catch (SecurityException e) {
 getSystemPropsFailed = true;
 return null;
 }
 }
 }
 );
 if (sysProps == null) {
 return null;
 }
 String[] jProps = new String[PROPS.length];
 for (int i = 0; i < PROPS.length; i++) {
 jProps = sysProps.getProperty(PROPS);
 }
 return jProps;
 }

 String getJndiProperty(final int i) {
 return (String) AccessController.doPrivileged(
 new PrivilegedAction() {
 public Object run() {
 try {
 return System.getProperty(PROPS);
 } catch (SecurityException e) {
 return null;
 }
 }
 }
 );
 }

In this funky looking code (which to be honest I don't understand the special bits) java.naming.provider.url and jnp://localhost:1099 are returned. I'm wondering
a) Why doesn't this appear in JBoss when starting that without the java.naming.provider.url in the jndi.properties
b) What the AccessController stuff does special to magically create the java.naming.provider.url=jnp://localhost:1099

Any ideas?

Cheers,

Kab

[acoliver]

Awsome, so its fixed? That was driving me nuts. Anything need to change in jndi.properties?

[kabirkhan]

jndi.properties is the same

[kabirkhan]

"kabkhan" wrote:
maybe it goes a bit away from the original intent, by us simply calling new InitialContext().bind()? I'm a bit confused!!!

Been reading up on naming and think it is kosher. I reckon the idea behind the FakeInitialContext is to use the contained HashMap of bindings, and not to have to rely on the NamingService. Is that correct?

[acoliver]

Calling the standard jboss InitialContext would have to connect to JBoss's naming service which we'd have to set up and bind stuff etc. Might work just as well if we take server/default/conf/jndi.properties and do it locally and register it in the depends-service.xml but for some reason I couldn't get it to work when I tried. I might have just left a step out so you could try it if you like.

[kabirkhan]

Hi,

I'm having a slight problem with the jndi stuff for the testing. I am trying to use the jboss naming service rather than the fake contet stuff.

I have set up the jndi.properties file to be:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Next I stepped through the org.jboss.naming.NamingService.startService() method. The first bit loads up the properties from the jndi.properties file and sets the in System.properties, as expected there is no java.naming.provider.url there. Also, when I do a System.getProperty("java.naming.provider.url") at any stage nothing is returned.

However, once the first InitialContext is created and it's environment got, java.naming.provider.url is there! (i.e. it is in env below)

 InitialContext iniCtx = new InitialContext();
 Hashtable env = iniCtx.getEnvironment();

I followed this through, and new InitialContext()
calls javax.naming.InitialContext.init() //This initialises the environment for the InitialContext
which calls javax.naming.internal.ResourceManager.getInitialEnvironment()
which calls javax.naming.internal.VersionHelper.getJndiProperties()

VersionHelper.getProperties() looks like this

 String[] getJndiProperties() {
 if (getSystemPropsFailed) {
 return null; // after one failure, don't bother trying again
 }
 Properties sysProps = (Properties) AccessController.doPrivileged(
 new PrivilegedAction() {
 public Object run() {
 try {
 return System.getProperties();
 } catch (SecurityException e) {
 getSystemPropsFailed = true;
 return null;
 }
 }
 }
 );
 if (sysProps == null) {
 return null;
 }
 String[] jProps = new String[PROPS.length];
 for (int i = 0; i < PROPS.length; i++) {
 jProps = sysProps.getProperty(PROPS);
 }
 return jProps;
 }

 String getJndiProperty(final int i) {
 return (String) AccessController.doPrivileged(
 new PrivilegedAction() {
 public Object run() {
 try {
 return System.getProperty(PROPS);
 } catch (SecurityException e) {
 return null;
 }
 }
 }
 );
 }

In this funky looking code (which to be honest I don't understand the special bits) java.naming.provider.url and jnp://localhost:1099 are returned. I'm wondering
a) Why doesn't this appear in JBoss when starting that without the java.naming.provider.url in the jndi.properties
b) What the AccessController stuff does special to magically create the java.naming.provider.url=jnp://localhost:1099

Any ideas?

Cheers,

Kab

[acoliver]

Great questions. I think this is probably about where I got when I gave up and did FakeIntialContext :-)

[kabirkhan]

I've been very naughty and have done a cross post regarding the jndi properties in order to reach a wider audience.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3830929#3830929

Adrian has some comments regarding how we set up our MBeans, Andy what do you think?

[kabirkhan]

I have commited the changes to the head branch, so that the mail services tests now use the normal jboss naming service.

Using Adrian's suggestion
Thread.currentThread().getContextClassLoader().getResources("jndi.properties");

uncovered that java.naming.provider.url is present in twiddle.jar.

To run the unit tests, REMOVE java.naming.provider.url from jndi.properties from twiddle.jar used in your classpath.

I'm slightly curious if this could have any implications on the twiddle stuff, but it shouldn't be too important at present?

Kab

[kabirkhan]

PS I could only get the NamingService to work "in-jvm", setting the ports to > 0 caused whole bunch of other problems.

[acoliver]

Twiddle is not the best written code in all of JBoss. Do not be afraid to make fixes to it, itself. At some point I want to make the twiddle stuff work as an example of *other* things that could be done as protocols on our stack. Plus there are things that could be done with it that might be useful (like a convienient way to set up temporary users, etc. in our script runner and an answer to JAMES's admin console thingy)..

[kabirkhan]

No longer any need to play around with twiddle.jar. Getting the naming service to work both "in-jvm" and with sockets was simply a case of setting the bind addresses in depens-service.xml.

Cheers,

Kab