Toplink Essentials в Resin 2 і не тільки

В продовження теми Toplink Essentials on Caucho Resin.

Як відомо Toplink Essentials являється Reference Implementation специфікації JPA і тому підтримує буквально два сервери - це SunAS9 i OC4J_10_1_3. Щоб пересвітчитись достатньо заглянути в клас oracle.toplink.essentials.config.TargetServer. З рештою серверів Toplink працює як в середовищі без підтримки JTA (при коміті ejb транзакції Toplink зміни в базу не синхронізує). 

Щоб добавити підтримку JTA для свого сервера потрібно створити два класи - перший це клас, що серверну платформу і повинен реалізовувати інтерфейс oracle.toplink.essentials.platform.server.ServerPlatform, як початковуреалізацію можна взяти клас oracle.toplink.essentials.platform.server.ServerPlatformBase. Головним методом в цьому класі є getExternalTransactionControllerClass, який повертає клас що вміє для конкретного сервера шукати референс на javax.transaction.TransactionManager. В нашому випадку це другий клас який потрібно сворити і наслідує він oracle.toplink.essentials.transaction.JTATransactionController. 

Назвемо перший клас ResinServerPlatform, а другий ResinTransactionController. ResinTransactionController повинен переопреділити метод acquireTransactionManager наступним чином

protected TransactionManager acquireTransactionManager() throws Exception {
  return (TransactionManager)jndiLookup("java:comp/UserTransaction");
 }

Тепер залишилося в persistence.xml прописати для властивості toplink.target-server значення ResinServerPlatform.

Я не наводжу повних кодів для класів, так як достатньо в сорцах подивитися на реалізацю oracle.toplink.essentials.platform.server.sunas.SunAS9ServerPlatform та oracle.toplink.essentials.transaction.sunas.SunAS9TransactionController і все стане зрозуміло.

І знову 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