12 Replies Latest reply on May 4, 2004 3:35 AM by Kabir Khan

    FakeInitialContext and java:/ root names

    Kabir Khan Master

      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

        • 1. Re: FakeInitialContext and java:/ root names
          Kabir Khan Master

          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

          • 2. Re: FakeInitialContext and java:/ root names
            Andrew Oliver Master

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

            • 3. Re: FakeInitialContext and java:/ root names
              Kabir Khan Master

              jndi.properties is the same

              • 4. Re: FakeInitialContext and java:/ root names
                Kabir Khan Master

                 

                "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?

                • 5. Re: FakeInitialContext and java:/ root names
                  Andrew Oliver Master

                  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.

                  • 6. Re: FakeInitialContext and java:/ root names
                    Kabir Khan Master

                    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

                    • 7. Re: FakeInitialContext and java:/ root names
                      Andrew Oliver Master

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

                      • 8. Re: FakeInitialContext and java:/ root names
                        Kabir Khan Master

                        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?

                        • 9. Re: FakeInitialContext and java:/ root names
                          Kabir Khan Master

                          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


                          • 10. Re: FakeInitialContext and java:/ root names
                            Kabir Khan Master

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

                            • 11. Re: FakeInitialContext and java:/ root names
                              Andrew Oliver Master

                              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)..

                              • 12. Re: FakeInitialContext and java:/ root names
                                Kabir Khan Master

                                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