[dmwm67]

yes javax.api and javax.transaction.api

[knightblue610]

Thanks for explaining about the difference between local and global modules.  Sorry I didn't reply earlier; was out yesterday.  If I am understanding correctly, that would make the module visible to all sub-deployments also, would it not?  If so, then perhaps I simply need to add an override to META-INF/services in each WAR of the EAR file with the global module, though first I have to figure out how to get Maven to do it.

[knightblue610]

OK, so adding overrides to the sub-WARs didn't work.  It would be a losing battle anyway as every library would also need an override.

[knightblue610]

OK, so I spent the whole day trying a bunch of different things.  I tried splitting the module up into three separate JARs and making one global, importing the others, as well as trying different dependency settings for each dependent module.  I tried having a separate copy of the libraries in my JAR file with a global and local module, and I tried importing the org.apache.xerces module through jboss-deployment-structure.xml (with services set to "import") with the xmlparserv2.jar as both a global and local module.

Then I decided to fight fire with fire, and made the org.apache.xerces module global, along with xmlparserv2.  Again, the application deployed, but it runs into the same NPE as originally.  I think that the Xerces implementation is stepping on something in the Oracle implementation, and that's why I see the error.  I wish I could be more descriptive than that, but based on what Stephen was saying, if it works as a global module, but it doesn't work when Xerces is in the classpath, then that points to some sort of conflict.

What I still don't understand is why the SPI override doesn't work, when xmlparserv2 is in a global module.  It seems like that should override it no matter what I put in global-modules.  I also don't get why trace logging me is telling me that the XMLType class is being loaded from org.jboss.as.controllers, when it should come out of the module. 

[knightblue610]

{quote}
This jar is a bit evil because it contains it's own copies of javax.xml, org.w3c.dom and org.xml.sax packages. Therefore, I'd make a custom version of this jar containing only the oracle.xml package and use that in conjuction with the server provided parsers and see how it goes.
It's likely that you will still need to deal with the META-INF/services jaxp configuration that also exists in that jar, but lets deal with that if we come to it.
{quote}

I tried this as well.  Newer versions of the xmlparserv2.jar (specifically, version 11.2.0.3) don't include their own version of the java.xml and other standard packages.  I actually used the Maven shade plugin to create a JAR that included the required XML api's along with the xdb and ojdbc6 packages for the JAR to load properly.  I tried shading it both with Xerces, and not xmlparserv2, and with xmlparserv2, and not Xerces.  In both cases, the same NullPointerException appears.

Do you have other ideas?  I must have tried this a hundred different ways.

Also, Mr. Gregg, may I ask what version of the Oracle libraries you were using when you made this global?

Thanks for all the help so far.

[sfcoy]

Hi Brad,

I think we may have been discussing slightly crossed diagnostics with the other Stephen.

First, it's good to see that someone at Oracle saw the problem with including the standard packages in that jar.

Can we wind back to using standard versions of everything, except the ojdbc6.jar. I think we should try ojdbc6_g.jar and activate it's tracing facility (some googling required!).

BTW, Oracle is pretty loose with their versioning. I have at least two versions of ojdbc6.jar here, both claiming to be "Implementation-Version: 11.2.0.3.0", but having different versions of oracle.jdbc.driver.NamedTypeAccessor within.

[knightblue610]

Hi Stephen,

Unfortunately, I can't get the tracing features to work under JBoss 7.  I replaced ojdbc6.jar with ojdbc6_g.jar, changed the module configuration, unpacked the OracleLog.properties file to C:, then added "-Doracle.jdbc.Trace=true -Djava.util.logging.config.file=c:\OracleLog.properties" to the JBoss startup options, but it had no effect.  I also tried adding those categories in the <subsystem xmlns="urn:jboss:domain:logging:1.1"> configuration in standalone-full.xml, but that also had no effect.

I tried Googling for similar problems and this is the closest that I could find:

https://community.jboss.org/thread/201293

Unfortunately, that question was never answered.  Do you have any other suggestions on how I could get this working?

Thanks for all of your help so far.

[sfcoy]

You should be able to add:

{code:xml}<connection-property name="oracle.jdbc.Trace">true</connection-property>{code}

elements to your <datasource>...</datasource> configuration.

I wouldn't worry about the logging config for now. Output should appear in JBoss logs.

[knightblue610]

I have added the connection-property as described and validated that the option appears in the Admin Console.  However, I'm still not seeing any trace output, either in the console or the logs.  Here is my logging configuration, perhaps I have done something wrong?

{code}
<subsystem xmlns="urn:jboss:domain:logging:1.1">
    <console-handler name="CONSOLE">
        <level name="INFO"/>
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
    </console-handler>
    <periodic-rotating-file-handler name="FILE">
        <level name="TRACE"/>
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="server.log"/>
        <suffix value=".yyyy-MM-dd"/>
        <append value="true"/>
    </periodic-rotating-file-handler>
    <logger category="com.arjuna">
        <level name="WARN"/>
    </logger>
    <logger category="org.apache.tomcat.util.modeler">
        <level name="WARN"/>
    </logger>
    <logger category="sun.rmi">
        <level name="WARN"/>
    </logger>
    <logger category="jacorb">
        <level name="WARN"/>
    </logger>
    <logger category="jacorb.config">
        <level name="ERROR"/>
    </logger>
    <!--
    <logger category="org.jboss.modules">
        <level name="TRACE" />
    </logger>
    -->
    <logger category="oracle.jdbc.level">
        <level name="TRACE" />
    </logger>
    <logger category="oracle.jdbc.driver.level">
        <level name="TRACE" />
    </logger>
    <root-logger>
        <level name="INFO"/>
        <handlers>
            <handler name="CONSOLE"/>
            <handler name="FILE"/>
        </handlers>
    </root-logger>
</subsystem>
{code}

[dmwm67]

I've been hacking with the oracle drivers and jboss modules to try and figure out why the XMLType from xdb6.jar is not found by ClassRef.java in the ojdbc6.jar file and have determined that the jboss.as.controller module first loads the oracle.driver module (in my case) and calls the contructor of the Oracle driver in that module. The constructor involves using the ClassRef class (in ojdbc6.jar) to find other classes which fails silently as it uses the classloader in the jboss.as.controller module to find XMLType.class. Under normal circumstances this is not an issue, only those using XMLType care. I added a dependency to jboss.as.controller on oracle.driver and it passed the initialization phase, but failed in my app as it used yet another classloader which again did not find the XMLType (the oracle driver was already loaded and did not have to be located again).

So, given this I tried the jboss-deployment-structure.xml file in both the EAR file and the EJB JAR file, but that did not seem to have any affect. Finally, I tried the manifest in the EJB jar file depending on oracle.driver and it all works as expected, but now I have a dependency on a module called "oracle.driver" in code (sort of) so we have to take care during deployment.

Hopefully if you try the manifest update it will solve your issue:

Manifest Entry:

Dependencies: oracle.driver

[knightblue610]

First off, I want to thank you for doing this.  I am really impressed at how you were able to figure out where to take the next step, and that you spent all of this time working on it.

Just to make sure I understand - the manifest entry goes in the sub-deployment, and I have to add the jboss.as.controller dependency in the module, right?

[dmwm67]

Yes, I currently have both of those dependencies, one in the sub deployment and the other in the jboss.as.controller module.xml. I haven't tried removing the jboss.as.controller dependency yet, but I suspect that will still work

[knightblue610]

Well, Stephen, you appear to have cracked this one wide open.

I wasn't able to get this working with just the manifest entry, but when I added the dependency in the org.jboss.as.controller module to oracle.driver, it worked.  I'm still getting the error "ORA-22922: nonexistent LOB value", but I'm confident that's the code and not the JBoss configuration.

I also learned that this works without changes using version 11.2.0.2 of the Oracle driver.  Apparently they broke something in 11.2.0.3.

So, the steps to get Oracle XMLType/SQLXML working with JBoss 7 are:

1. Create a new module called "oracle.driver".

2. Add the files "ojdbc6.jar", "xdb6.jar", "orai18n.jar", "orai18n-collation.jar", and "xmlparserv2.jar" to the module.

3. In your manifest of your sub-deployment (EJB JAR or WAR file) add:

Dependencies: oracle.driver

4. Edit the dependencies of the org.jboss.as.controller module that comes preinstalled with JBoss to add a dependency on "oracle.driver" (yes, you heard that right, you have to edit the module for a JBoss system dependency.)

Thank you SO MUCH for your help!

[sgoschin]

Hi Brad,

i had the same problem with JBoss, while it was working locally.

Because i didn't wanted to configure the oracle drivers inside of a JBoss module I just left them locally in a lib folder. So that the same app also would run on other applications servers.

So i couldn't apply the solution of a global module. However, while debugging where the NullPointerException is coming from I found a nice easy solution.

It seems that the JBoss 7 AS has a problem to load one particular class, in oracle.jdbc.driver.NamedTypeAccessor.getOracleObject(NamedTypeAccessor.java:302). However this class can be loaded before and then the error disappears.

The only thing you have to do is adding

     Class.forName("oracle.xml.binxml.BinXMLMetadataProvider");

in the initial phase and the problem was solved.

This class is part of the xmlparserv2.jar which can be found e.g. in the XML Developer Kit.