І знову XML паресер

Тільки тепер уже разом з Digester i Resin. Чесно кажучи, не долюблюю я Resin саме через його гнучкість. У Resin є можливість добавити системні властивості на рівні хоста(і не тільки). Так от, якщо ви, наприклад, маєте проект зі struts, який використовує digester, в classpath є xerces, але як парсер на рівні хоста вказаний не xerces, а скажімо com.caucho.xml.parsers.XmlSAXParserFactory, то виходить цікава картина: Digester бачить, що в системі є xerces і пускає логіку по шляху який зав"язаний на xerces, але на справді інітиться резіновська XmlSAXParserFactory. Ну і відповідно отримуємо екшепшен.
Щоб його позбутися прибираємо xerces з classpath, або вказуємо як парсер org.apache.xerces.jaxp.SAXParserFactoryImpl

Java "dll hell"

Буквально на днях стикнувся з таким явищем як "dll hell" тільки в яві. Зараз практично жоден проект має xml файли і, як результат, потребує парсера. Є в мене в Resin кілька проектів, і що саме дивне, одна і та сама копія Resin з проектами на одних серверах працює нормально, а на інших ні - весь час свариться на JAXP парсер.
Виявилося, що розгадка в тому як шукається і інітиться парсер. Спершу шукається системна властивість javax.xml.parser.SAXParserFactory - якщо її не вказано, то шукається в classpath файл \META-INF\services\javax.xml.parsers.SAXParserFactory - ось тут і була проблема. В Resin два jar файли має такий файл і в них описані різні парсери - org.apache.crimson.jaxp.SAXParserFactoryImpl і com.caucho.xml.parsers.XmlSAXParserFactory.
От і виходило, що на одних системах getResourceAsStream повертав одне значення, а на інших - інше.
Мораль цієї історії така - все повинно бути описано в проекті строго настрого.