if you are developing a JEE applications, if haven't yet, one day you might face exceptions due to loading wrong SAX implementation. and if you are producing an ear then it makes more difficult to understand reasons behing.
think that you are using jdk 1.6 and want to use SAX in your application. it is very easy, since jdk1.6 contains sax implementation without anything you can. if you decided to use apaches xerces imp. , then you must put related jar to your ears classpath.
but how these additional classes being picked up, despite exact same classes are in jdk's classpath.
basic rule in java whist loading a class is, if you have a parent classloader then delegate this loading action to parent classloader. if it can not find then try to load class by own.
factory finder in SAX Specification looks system parameter, then JAVA_HOME/lib/jaxp.properties, then META-INF/services/javax.xml.parsers.SAXParserFactory respectively.
in such case like using an application server like weblogic, if you put xerces implementation inside your ear, if you don't specify any special parameter then 3th option picked up the related implementation. but how, since weblogic also contains its own sax implementation. and your implementation is to deep to select by java.
answer is Thread.currentThread().getContextClassLoader() .
by default, jaxp is using Thread.currentThread().getContextClassLoader() to load resources. becuase applicaiton server in our case weblogic set this classloader with ears or wars classloader while thread is being created, from the point of this classloader your ear's classpath is the first order contrary to java classloading order.
with Thread.currentThread().getContextClassLoader() classloader, META-INF/services/javax.xml.parsers.SAXParserFactory is loaded from you ear. and this file contains while line information. sax implementations class. then classloader loads this class wherever this class exist.
think that you are using jdk 1.6 and want to use SAX in your application. it is very easy, since jdk1.6 contains sax implementation without anything you can. if you decided to use apaches xerces imp. , then you must put related jar to your ears classpath.
but how these additional classes being picked up, despite exact same classes are in jdk's classpath.
basic rule in java whist loading a class is, if you have a parent classloader then delegate this loading action to parent classloader. if it can not find then try to load class by own.
factory finder in SAX Specification looks system parameter, then JAVA_HOME/lib/jaxp.properties, then META-INF/services/javax.xml.parsers.SAXParserFactory respectively.
in such case like using an application server like weblogic, if you put xerces implementation inside your ear, if you don't specify any special parameter then 3th option picked up the related implementation. but how, since weblogic also contains its own sax implementation. and your implementation is to deep to select by java.
answer is Thread.currentThread().getContextClassLoader() .
by default, jaxp is using Thread.currentThread().getContextClassLoader() to load resources. becuase applicaiton server in our case weblogic set this classloader with ears or wars classloader while thread is being created, from the point of this classloader your ear's classpath is the first order contrary to java classloading order.
with Thread.currentThread().getContextClassLoader() classloader, META-INF/services/javax.xml.parsers.SAXParserFactory is loaded from you ear. and this file contains while line information. sax implementations class. then classloader loads this class wherever this class exist.
Yorumlar
Yorum Gönder