4 Replies Latest reply on Nov 16, 2016 2:07 AM by osamu.nagano

    sun.net.spi.nameservice.provider jboss-eap-6.3.3 not respected

    xandrewrampulla

      I have been trying to replace the DNS provider in JBoss-EAP-6.3.3 for a few days now and I'm stuck.  I modified standalone.sh to include -Dsun.net.spi.nameservice.provider.1=dns,MyNameResolver and replaced the -jar jboss-modules.jar with

      -cp "/opt/jboss-as/standalone/lib/ext/cachingdnsnameresolver.jar:/opt/jboss-as/jboss-modules.jar" org.jboss.modules.Main

       

      Yet no matter what I do I cannot get the DNS resolver in my cachingdnsresolver.jar to get picked up.  When I the same thing with a simple java command line application I have no problem.

      ava -Dsun.net.spi.nameservice.provider.1=dns,MyNameResolver  -cp cachingdnsnameresolver.jar:dnslookup-1.0-SNAPSHOT.jar net.example.dnslookup.Main www.google.com

       

      This then prints to STDOUT when my resolver's constructor is called, yet in JBoss I can't find this output anywhere.

       

      Does anyone have any ideas on what this might be?  I'm assuming JBoss is messing with the security manager in some way to prevent loading of this class, but I couldn't figure out how.

       

      Thanks in advance

        • 1. Re: sun.net.spi.nameservice.provider jboss-eap-6.3.3 not respected
          xandrewrampulla

          Another interesting data point.  If I write a class whose main function does an InetAddress.getByName and then invokes org.jboss.modules.Main.main(String[] args), I can get my custom DNS resolver to be used.  This implies JBoss is doing something early on in the process to explicitly exclude my resolver.  Still have no clue why though.

          • 2. Re: sun.net.spi.nameservice.provider jboss-eap-6.3.3 not respected
            jaikiran

            It's a bit tricky, but I think doable. Looking at the InetAddress class, it does the nameservers initialization in a static block of that class and uses Thread context classloader to find any custom defined nameservers. So what this means is you will have to do something like this on a fresh install of the WildFly/JBoss EAP server:

             

            1. Create a JBoss module for your custom nameserver provider. There's documentation on how to do this in relevant server/JBoss modules docs. If you don't find it, please ask either in this thread or a new one. Assume you name that module "com.mycompany.dnsprovider".

             

            2. Edit the module.xml of org.jboss.modules to add a dependency on your custom module *and* set the services=import attribute to true. Something like:

             

            <dependencies>

            ....

                    <module name="com.mycompany.dnsprovider" services="import"/>

             

            3. In the stanadlone.conf (or relevant startup config file) pass the sun.net.spi.nameservice.provider.n system property in the JAVA_OPTS section:

             

            -Dsun.net.spi.nameservice.provider.1=dns,MyNameResolver

             

             

            I think that should be it.

             

            P.S: It's still not 100% fool proof but yet will "almost always" work because I think you can probably expect the InetAddress class to be accessed very early in the JBoss module bootup process that it will trigger the static block initialization of that class in the context of the org.jboss.module module's classloader.

            • 3. Re: sun.net.spi.nameservice.provider jboss-eap-6.3.3 not respected
              ipvsbu_drampull

              Thanks for the try, but this still doesn't work.  I tried making a module for my jar and add it to org.jboss.modules as you suggested, but it still does not appear to be loaded.

              • 4. Re: sun.net.spi.nameservice.provider jboss-eap-6.3.3 not respected
                osamu.nagano