1 Reply Latest reply on Aug 28, 2015 12:32 PM by John Liptak

    JBoss EAP 6.3.1 Hibernate Oracle xml type - ojdbc version issue

    Sandeep Kumar Newbie

      I am using user defined hibernate UserType for oracle  XMLTYPE.

      Here is the code for nullSafeGet in usertype

      @Override
      public Object nullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner) throws HibernateException, SQLException {

        
      XMLType xmlType = null;
        
      Document doc = null;
        
      String returnValue = null;
        
      try {
        
      //logger.debug("rs type: " + rs.getClass().getName() + ", value: " + rs.getObject(names[0]));
        xmlType
      = (XMLType) rs.getObject(names[0]);

        
      if (xmlType != null) {
        returnValue
      = xmlType.getStringVal();
        
      }
        
      } finally {
        
      if (null != xmlType) {
        xmlType
      .close();
        
      }
        
      }
        
      return returnValue;
      }


      When i tested it on jboss eap 6.3.1 running on my local it worked fine but when i moved the code to server(running eap 6.3.1) it threw exception at  rs.getObject(names[0]).

      I did some triage and found out the ojdbc jar i had on my local jboss vs server jboss were different, i copied the ojdbc jar from server to my local jboss installation and manged to produce same error.

       

      Server has jndi defined and that is what application is using.

       

      Now problem is i cannot change the server ojdbc with mine. I can package my local ojdbc with application (maven), is there a way to override the server ojdbc module with the one packaged in application and make sure jndi is using packaged driver.

        • 1. Re: JBoss EAP 6.3.1 Hibernate Oracle xml type - ojdbc version issue
          John Liptak Newbie

          Not really - you can package the jar file, but the datasource will still be backed by the module that supports the driver registered.  This can lead to class cast exceptions. In our environment, we also don't allow applications to alter the JDBC drivers we supply; however, we do let them add modules and run CLI scripts.  With that, applications can register their own drivers.  So as long as they use a custom name, they can use their own Oracle JDBC drivers (and additional jar files for say the _g debugging versions). The trick is to use the -mp module path to allow you to add module directories and then register the driver and create the datasource using your newly installed ojdbc version.