13 Replies Latest reply on Jul 10, 2013 2:57 AM by jaikiran

    OpenESB Subsystem Extension

    brasseld

      Hi all,

       

      I'm currently working on a JBoss AS 7 extension.

      Creating the subsystem was quite easy but now I've got an error when I'm trying to use JAXB marshaller and unmarshaller :

      13:10:05,332 ERROR [stderr] (Timer-1) Exception in thread "Timer-1" java.lang.Error: javax.xml.datatype.DatatypeConfigurationException: Provider __redirected.__DatatypeFactory not found
      13:10:05,333 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:907)
      13:10:05,333 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$22.parse(RuntimeBuiltinLeafInfoImpl.java:794)
      13:10:05,334 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$22.parse(RuntimeBuiltinLeafInfoImpl.java:797)
      13:10:05,334 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.parse(TransducedAccessor.java:247)
      13:10:05,335 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.startElement(StructureLoader.java:209)
      13:10:05,336 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:501)
      13:10:05,336 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480)
      13:10:05,336 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.ValidatingUnmarshaller.startElement(ValidatingUnmarshaller.java:102)
      13:10:05,337 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:150)
      13:10:05,337 ERROR [stderr] (Timer-1)           at org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:496)
      13:10:05,337 ERROR [stderr] (Timer-1)           at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:283)
      13:10:05,338 ERROR [stderr] (Timer-1)           at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(XMLNSDocumentScannerImpl.java:733)
      13:10:05,338 ERROR [stderr] (Timer-1)           at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1754)
      13:10:05,339 ERROR [stderr] (Timer-1)           at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)
      13:10:05,340 ERROR [stderr] (Timer-1)           at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:845)
      13:10:05,340 ERROR [stderr] (Timer-1)           at org.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:768)
      13:10:05,341 ERROR [stderr] (Timer-1)           at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)
      13:10:05,341 ERROR [stderr] (Timer-1)           at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1196)
      13:10:05,341 ERROR [stderr] (Timer-1)           at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:555)
      13:10:05,342 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:217)
      13:10:05,342 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:189)
      13:10:05,343 ERROR [stderr] (Timer-1)           at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:136)
      13:10:05,344 ERROR [stderr] (Timer-1)           at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:183)
      13:10:05,344 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.repository.Archive.loadJbiXml(Archive.java:480)
      13:10:05,345 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.repository.Archive.parseArchive(Archive.java:347)
      13:10:05,345 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.repository.Archive.<init>(Archive.java:146)
      13:10:05,345 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.system.AutoAdminTask.doInstall(AutoAdminTask.java:353)
      13:10:05,346 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.system.AutoAdminTask.performAutoInstall(AutoAdminTask.java:331)
      13:10:05,346 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.system.AutoAdminTask.performAutoFunctions(AutoAdminTask.java:288)
      13:10:05,346 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.system.AdminService.heartBeat(AdminService.java:972)
      13:10:05,347 ERROR [stderr] (Timer-1)           at com.sun.jbi.management.system.AdminService.handleNotification(AdminService.java:199)
      13:10:05,347 ERROR [stderr] (Timer-1)           at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
      13:10:05,348 ERROR [stderr] (Timer-1)           at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:274)
      13:10:05,348 ERROR [stderr] (Timer-1)           at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:339)
      13:10:05,349 ERROR [stderr] (Timer-1)           at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:324)
      13:10:05,349 ERROR [stderr] (Timer-1)           at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:247)
      13:10:05,349 ERROR [stderr] (Timer-1)           at javax.management.timer.Timer.sendNotification(Timer.java:1235)
      13:10:05,350 ERROR [stderr] (Timer-1)           at javax.management.timer.Timer.notifyAlarmClock(Timer.java:1197)
      13:10:05,350 ERROR [stderr] (Timer-1)           at javax.management.timer.TimerAlarmClock.run(Timer.java:1286)
      13:10:05,350 ERROR [stderr] (Timer-1)           at java.util.TimerThread.mainLoop(Timer.java:555)
      13:10:05,351 ERROR [stderr] (Timer-1)           at java.util.TimerThread.run(Timer.java:505)
      13:10:05,351 ERROR [stderr] (Timer-1) Caused by: javax.xml.datatype.DatatypeConfigurationException: Provider __redirected.__DatatypeFactory not found
      13:10:05,352 ERROR [stderr] (Timer-1)           at javax.xml.datatype.DatatypeFactory.newInstance(DatatypeFactory.java:135)
      13:10:05,352 ERROR [stderr] (Timer-1)           at com.sun.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:905)
      13:10:05,352 ERROR [stderr] (Timer-1)           ... 40 more
      13:10:05,353 ERROR [stderr] (Timer-1) Caused by: java.lang.ClassNotFoundException: __redirected/__DatatypeFactory
      13:10:05,353 ERROR [stderr] (Timer-1)           at java.lang.Class.forName0(Native Method)
      13:10:05,353 ERROR [stderr] (Timer-1)           at java.lang.Class.forName(Class.java:270)
      13:10:05,354 ERROR [stderr] (Timer-1)           at javax.xml.datatype.FactoryFinder.getProviderClass(FactoryFinder.java:126)
      13:10:05,354 ERROR [stderr] (Timer-1)           at javax.xml.datatype.FactoryFinder.newInstance(FactoryFinder.java:181)
      13:10:05,354 ERROR [stderr] (Timer-1)           at javax.xml.datatype.FactoryFinder.newInstance(FactoryFinder.java:150)
      13:10:05,355 ERROR [stderr] (Timer-1)           at javax.xml.datatype.FactoryFinder.find(FactoryFinder.java:222)
      13:10:05,355 ERROR [stderr] (Timer-1)           at javax.xml.datatype.DatatypeFactory.newInstance(DatatypeFactory.java:129)
      13:10:05,355 ERROR [stderr] (Timer-1)           ... 41 more
      
      

       

      Here is my module.xml :

      <module xmlns="urn:jboss:module:1.0" name="net.openesb.jboss7">
          <resources>
              <resource-root path="openesb-jboss7-subsystem.jar"/>
              <resource-root path="jbi_rt.jar"/>
              <resource-root path="jbi.jar"/>
              <resource-root path="jbi-ext.jar"/>
          </resources>
      
          <dependencies>
              <module name="javax.api"/>
              <module name="javax.xml.bind.api" />
              <module name="com.sun.xml.bind" />
              <module name="org.jboss.staxmapper"/>
              <module name="org.jboss.as.controller"/>
              <module name="org.jboss.as.server"/>
              <module name="org.jboss.modules"/>
              <module name="org.jboss.msc"/>
              <module name="org.jboss.logging"/>
              <module name="org.jboss.vfs"/>
          </dependencies>
      </module>
      
      

       

      As you can see in the stack trace, we are in the context of a JMX notification (that's why we are in Timer-1 thread).

      The current classloader of the class (com.sun.jbi.management.system.AdminService) which handles the notification is my module classloader (that sounds good according to me). But still don't know why the __redirected/__DatatypeFactory on this part of my service extension.

       

      Ce message a été modifié par: David Brassely

        • 1. Re: OpenESB Subsystem Extension
          jaikiran

          Which exact version of AS7 is this?

          • 2. Re: OpenESB Subsystem Extension
            brasseld

            It's 7.1.1.Final

            • 3. Re: OpenESB Subsystem Extension
              jaikiran

              Could you give this a try against latest WildFly released version http://wildfly.org/download/?

              • 4. Re: OpenESB Subsystem Extension
                brasseld

                I've exactly the same problem... (but in red in my console )

                • 5. Re: OpenESB Subsystem Extension
                  ctomc

                  Hi,

                   

                  can you come to freenode irc channel #wildfly-dev it will be easier to help you.

                  you can ping me (ctomc) or anyone else....

                   

                  Also what does your deployment look like, i am asumming that there is some kind of deplyoment involved.

                   

                  that _redirected_ stuff are classes that jboss-modules boot classloader overrides/redirects so it can support custom xml parsers (David can confirm / beter explain then me)

                   

                  my guess would be that there is something clashing with jaxb parser, maybe some fantom jar somewhere...

                  • 6. Re: OpenESB Subsystem Extension
                    brasseld

                    Tomaz,

                     

                    Please have a look to this : (hope it can help you)

                     

                    In the module subsystem context :

                    INFO  [net.openesb] (MSC service thread 1-8) Current Classloader : ModuleClassLoader for Module "net.openesb.jboss7:main" from local module loader @15adb0d5 (roots: /Users/david/java-ext/jboss/jboss-as-7.1.1.Final/modules)

                    INFO  [net.openesb] (MSC service thread 1-8) Context Classloader : ModuleClassLoader for Module "net.openesb.jboss7:main" from local module loader @15adb0d5 (roots: /Users/david/java-ext/jboss/jboss-as-7.1.1.Final/modules)

                     

                    In the MBean context :

                    INFO  (Timer-1) Current Classloader : ModuleClassLoader for Module "net.openesb.jboss7:main" from local module loader @15adb0d5 (roots: /Users/david/java-ext/jboss/jboss-as-7.1.1.Final/modules)

                    INFO  (Timer-1) Context Classloader : null

                     

                    Regards,

                    • 7. Re: OpenESB Subsystem Extension
                      jaikiran

                      David Brassely wrote:

                       

                      In the MBean context :

                      INFO  (Timer-1) Current Classloader : ModuleClassLoader for Module "net.openesb.jboss7:main" from local module loader @15adb0d5 (roots: /Users/david/java-ext/jboss/jboss-as-7.1.1.Final/modules)

                      INFO  (Timer-1) Context Classloader : null

                       

                       

                      I think it's this bug https://issues.jboss.org/browse/WFLY-822

                      • 8. Re: OpenESB Subsystem Extension
                        brasseld

                        jaikiran pai a écrit:

                         

                        I think it's this bug https://issues.jboss.org/browse/WFLY-822

                         

                        According to my understanding, it seems that this issue is more about a bad TCCL and not a null TCCL, or I missed probably something...

                        Is there any workaround to specify the TCCL while creating and invoking an MBean ?

                        • 9. Re: OpenESB Subsystem Extension
                          ctomc

                          It is bit different,

                           

                          in this case there is no user deployment, mbeans are registered as part of subsystem add

                           

                          https://bitbucket.org/openesb/openesb-jboss-v7/src/11baaaf80dc1/jboss7-subsystem/src/main/java/net/openesb/jboss7?at=master

                          • 10. Re: OpenESB Subsystem Extension
                            jaikiran

                            I'm pretty sure it's the same issue although I don't want to sound overconfident

                             

                            What that JIRA has uncovered is that the context classloader gets set to the classloader of the MBean instance. Now in that specific case explained in the JIRA, the MBean instance classloader happens to be the module classloader of the static module in which the MBean class resides. On the other hand, in the case being discussed in this thread, the MBean instance classloader happens to be the boot classloader (I see some com.sun classes involved in that stacktrace which gives a hint that the MBean might have been instantiated by the boot classloader).

                             

                            I think I can fix that issue in the next few minutes and perhaps David can give it a try to see if it works for him too.

                            • 11. Re: OpenESB Subsystem Extension
                              jaikiran

                              jaikiran pai wrote:

                               

                              I'm pretty sure it's the same issue although I don't want to sound overconfident

                               

                              I'm glad I added a disclaimer there Just after I posted my previous reply, I looked at this stacktrace again and realized that this isn't the typical *-service.xml MBean thing which effectively means that, as Tomaz says, that JIRA isn't applicable here.

                               

                              However, the issue David is running into appears to be similar - i.e. an incorrect TCCL on that invocation. The fix, I think, would be to set the correct TCCL, by the relevant (entry point) code, to the module classloader. I'll have to look at that openesb code to see what the right place is to do the TCCL switch or perhaps David knows?

                              • 12. Re: OpenESB Subsystem Extension
                                brasseld

                                jaikiran pai a écrit:

                                 

                                However, the issue David is running into appears to be similar - i.e. an incorrect TCCL on that invocation. The fix, I think, would be to set the correct TCCL, by the relevant (entry point) code, to the module classloader. I'll have to look at that openesb code to see what the right place is to do the TCCL switch or perhaps David knows?

                                Already done this and it works perfectly !

                                So the workaround is to check if the TCCL is null and, in this particular case, we have to set it with the module classloader.

                                 

                                The ugly thing comes when you have multiple MBean which means that you have to apply this workaround for each of them...

                                 

                                One more question is : OpenESB is container agnostic so I don't want to include specific code for each container. The "is null" condition sounds good to me but I'm searching for a way to know if we are in a JBoss context without having to import any class from JBoss. Is there any way to do this ?

                                 

                                Anyway, do I have to fill a JIRA issue for this ?

                                • 13. Re: OpenESB Subsystem Extension
                                  jaikiran

                                  David Brassely wrote:

                                   

                                  jaikiran pai a écrit:

                                   

                                  However, the issue David is running into appears to be similar - i.e. an incorrect TCCL on that invocation. The fix, I think, would be to set the correct TCCL, by the relevant (entry point) code, to the module classloader. I'll have to look at that openesb code to see what the right place is to do the TCCL switch or perhaps David knows?

                                  Already done this and it works perfectly !

                                  So the workaround is to check if the TCCL is null and, in this particular case, we have to set it with the module classloader.

                                  That's not actually a workaround. That's how it should be fixed. Furthermore, there's no need for a null check, it should always be switched to the appropriate classloader, which in this case based on your description is the module classloader.

                                   

                                   

                                  David Brassely wrote:

                                   

                                  The ugly thing comes when you have multiple MBean which means that you have to apply this workaround for each of them...

                                   

                                  That's the reason why I was looking for an "entry point". I have no clue about OpenESB and how it functions and how the MBeans are invoked. But the bottomline is that, if a certain MBean is expecting the TCCL to be set to a particular classloader (like in this case), then either it or the wrapping code (container perhaps) should switch the TCCL appropriately.

                                   

                                   

                                  David Brassely wrote:

                                   

                                  One more question is : OpenESB is container agnostic so I don't want to include specific code for each container. The "is null" condition sounds good to me but I'm searching for a way to know if we are in a JBoss context without having to import any class from JBoss. Is there any way to do this ?

                                   

                                  Anyway, do I have to fill a JIRA issue for this ?

                                  The TCCL switch would be needed even if it's outside JBoss since you can't guarantee the TCCL to be the "correct" one unless you yourself have set it. As for a JIRA, I don't see anything that JBoss can do here because none of that code is related to the application server. If it was a EE component or a MBean triggered by a JBoss specific *-service.xml then JBoss container would have done the necessary infrastructure setup like setting the TCCL before letting the MBean invocation go through. In this case, there's nothing we can fix.