Why are you using org.exolab.jms.jndi.InitialContextFactory? Why not use org.jboss.naming.remote.client.InitialContextFactory which ships with Wildfly?
Using org.jboss.naming.remote.client.InitialContextFactory works absolutely fine for me in my standalone. But the challenge we are facing is that we are trying to upgrade from jboss 7 to wildfly 10. But my client application is legacy application which is built on jdk 1.6. So there we are facing version compatible error because using org.jboss.naming.remote.client.InitialContextFactory as initial context factory requires jboss-client jar of widlfy which requires jdk 8. That's why we are trying to use org.exolab.jms.jndi.InitialContextFactory to post.
The simple fact of the matter is that if you want to use JNDI with Wildfly 10 then you'll need to use the initial context factory shipped with Wildfly 10 (i.e. org.jboss.naming.remote.client.InitialContextFactory) or re-implement one of your own that will do the job. org.exolab.jms.jndi.InitialContextFactory was written to work with OpenJMS's JNDI implementation, not Wildfly's.
As far as you still needing to use JDK 1.6...That version stopped receiving public updates over 4 years ago. Most of world has moved on since then to later versions.