XSL FO неисправного XSLT перевода в JBOSS AS 7

Question

У меня есть следующий код

SAXTransformerFactory stfactory; 
stfactory = (SAXTransformerFactory) TransformerFactory.newInstance(); 

/// ClassLoaderUriResolver is another class. 
stfactory.setURIResolver(new ClassLoaderUriResolver()); 

InputStream is = this.getClass().getClassLoader().getResourceAsStream("xsl/Hello.xsl"); 
StreamSource streamSource = new StreamSource(is); 

    mergeHandler = stfactory.newTransformerHandler(streamSource); 

XMLReader xmlReader = XMLReaderFactory.createXMLReader(); 

и некоторый код .....

Проблема заключается в линии mergeHandler = stfactory .newTransformerHandler (StreamSource);

Когда я запускаю эту программу как отдельную программу JAVA в JBOSS IDE с тем же набором банок

• Xalan-2.7.0.jar
• xercesImpl-2.7.1.jar
• XML-АПИС-1.3.04.jar
• XML-АПИС-доб-1.3.04.jar

Я вижу, что в stfactory.newTrans вызовов formerHandler (StreamSource);

возвращает
org.apache.xalan.transformer.TransformerHandlerImpl

и МОЯ XLST перевод прекрасно работает как простой Java программы

Где, как и тот же код, когда он работает на Jboss AS 7 container Я вижу, что вызов stfactory.newTransformerHandler (streamSource);

возвращает
org.apache.xalan.transformer.TransformerIdentityImpl (Не TransformerHandlerImpl)

В результате, когда я бег на Jboss AS 7 контейнера как часть веб-applicataion перевод XSLT не происходит, и я не вижу никаких ошибок. Мой документ XLS FO не переведен.

Как заставить код использовать org.apache.xalan.transformer.TransformerHandlerImpl?

Answer 1

У меня это работает.

В jboss в дополнение к модулям, которые мы можем исключить, есть еще одна банка, которая находится в корне C: \ jboss-eap-6.0 \ jboss-modules.jar. Внутри этой банки есть папка с именем «__redirected» с классом __TransformerFactory.class со следующим кодом.

Class clazz = __RedirectedUtils.loadProvider(id, javax/xml/transform/TransformerFactory, loader); 

Это заставляет «org.apache.xalan.processor.TransformerFactoryImpl», который будет загружен из C: \ JBoss-шр-6,0/JBoss-modules.jar

Однако это не модуль так Я не могу исключить его с помощью jboss-deployment-structure.xml, хотя я исключал следующие модули jboss для Xalan, Xercel и XML api. Поскольку у нас есть определенные банки в EAR lib, чтобы удовлетворить это.

jboss-deployment-structure.XML

<jboss-deployment-structure xmlns:p="urn:jboss:deployment-structure:1.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
      <deployment> 
          <exclusions> 
              <module name="org.apache.xerces" /> 
              <module name="org.apache.xalan" /> 
              <module name="org.apache.xml-resolver" /> 
          </exclusions> 

      </deployment> 

Так прокомментировал я следующий код

stfactory = (SAXTransformerFactory) TransformerFactory.newInstance(); 

и добавил

Class clazz = Class.forName("org.apache.xalan.processor.TransformerFactoryImpl"); 
    stfactory = (SAXTransformerFactory) clazz.newInstance(); 

Теперь я вижу, что

• org.apache.xalan.processor.TransformerFactoryImpl становится загружен из C: /jboss-eap-6.0/standalone/deployments/TST.ear/lib/xalan-2.7.0.jar

• stfactory.newTransformerHandler вызов (StreamSource) возвращает «org.apache.xalan.transformer.TransformerHandlerImpl», а не «org.apache.xalan.transformer.TransformerIdentityImpl»

Так что я считаю, что банку «C: \ jboss-eap-6.0 \ jboss-modules.jar "является частью загрузчика классов и выше загрузчика классов EAR. Поэтому он не использовал Xalan.2.7.0.jar для «org.apache.xalan.processor.TransformerFactoryImpl». Однако, когда мы вызываем stfactory.newTransformerHandler (streamSource), он возвращает «org.apache.xalan.transformer.TransformerIdentityImpl» .

Возможно, что-то погребено в C: \ jboss-eap-6.0 \ jboss-modules.jar для этого поведения.

Что я не понимаю в одном из тестов, я использовал Xalan.2.7.0.jar и добавил, что в java.endorsed.dir он все еще использовал C: \ jboss-eap-6.0 \ jboss-modules .jar, что мало удивительно, поскольку я думал, что одобренные банки будут загружены еще до C: \ jboss-eap-6.0 \ jboss-modules.jar.

Но в любом случае текущее исправление устраняет проблему, и это происходит только на сервере приложений Jboss 7. Код работает без каких-либо изменений в Webspshere 7.0, а также когда я запускаю его как автономную java-программу.