Sorry for the delay in replying but I was sent away on some training. yup ! you were right. The -ds.xml did not have the classes in scope to load the con-factories. I should have thought of it before. I subsequently tried the following two approaches and they both worked, 1) Included the -ds.xml as part of the ear and also deployed it as a service in the jboss-app.xml file (as you mentioned) 2> Included the -ds.xml at the root of the ear However both of the solutions have a problem in the sense that it is harder to change the configuration.Now is that going to be a limitation if we want to acheive the logging integration or is there a solution for that ? I also read this article, http://wiki.jboss.org/wiki/JBossClassLoadingUseCases?action=e&windows..., which kind of opened my eyes :o) Since you had a hand in the making the doc, could you be kind enough to clarify a basic doubt I have ? In case3: The UCL's parent, HierarchicalLoaderRepository3$NoParentClassLoader, overrides loadClass() to always throw a ClassNotFoundException, thus forcing the UCL to only load from its URLs. This ensures that the deployment is always scoped | | But then the child repository also calls getPackageClassLoaders() on its parent, and also includes into the returned class loader set a UCL (constructed on the spot and associated to the child repository) that has among its ancestors an instance of NoAnnotationURLClassLoader, which ultimately can reach the system class loader. | | I guess this is required in order to load basic java classes (like String etc) but would this not be defeating the above purpose as the NoParentClassLoader's immediate parent is the NoAnnotationURLClassLoader itself | | This makes it similar to the Case4 situation where there is no NoParentClassLoader in between. | | What exactly is the difference between the above two ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158635#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...