I read about this, during the weekend, in the apache xerces project page. Turns out, this is a common issue with all application server and they have a FAQ for this specific issue which explains the details http://xerces.apache.org/xerces2-j/faq-general.html#faq-5. JBoss AS runs into this exact issue. "rodos77" wrote : | IMHO, I think the deployer should either do this after it instantiates the parser or it should temporarily swap out the context classloader and swap in the deployer classloader in its place The deployers use JBossXB: | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:97) | at org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:56) | at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(Unmarsha | llerFactory.java:96) | So i guess its the responsibility of JBoss XB to switch the classloader. I am not an expert of xml or JBossXB. So i guess the best place to bring this up, is the JBossXB forum here http://www.jboss.org/index.html?module=bb&op=viewforum&f=212 "jaikiran" wrote : | From what i looked at, the deployment framework starts using the version of xerces jar present in your deployment because it sets the classloader to your deployment's classloader. I think this is the correct thing to do, because each deployment is expected to be started within its own classloader to ensure that it gets access to the right resources. Switching the classloader should be done only for the xerces issue, the rest of the deployment process should continue to use the deployment's classloader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249883#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...