Announcement Announcement Module
Collapse
No announcement yet.
dialect=org.hibernate.dialect.MySQL5InnoDBDialect failing on startup Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • dialect=org.hibernate.dialect.MySQL5InnoDBDialect failing on startup

    When I try to start my grails application, I get the following error with partial stacktrace):


    Code:
    | Error Error executing script RunApp: INSTANCE (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
    java.lang.NoSuchFieldError: INSTANCE
    	at org.hibernate.dialect.Dialect.<clinit>(Dialect.java:119)
    	at DataSource$_run_closure3_closure4_closure7.class$(DataSource.groovy)
    	at DataSource$_run_closure3_closure4_closure7.$get$$class$org$hibernate$dialect$MySQL5InnoDBDialect(DataSource.groovy)
    	at DataSource$_run_closure3_closure4_closure7.doCall(DataSource.groovy:19)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource$_run_closure3_closure4_closure7.doCall(DataSource.groovy)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource$_run_closure3_closure4_closure7.call(DataSource.groovy)
    	at java_util_concurrent_Callable$call.call(Unknown Source)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource.invokeMethod(DataSource.groovy)
    	at DataSource$_run_closure3.invokeMethod(DataSource.groovy)
    	at DataSource$_run_closure3_closure4.doCall(DataSource.groovy:16)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource$_run_closure3_closure4.doCall(DataSource.groovy)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource$_run_closure3_closure4.call(DataSource.groovy)
    	at java_util_concurrent_Callable$call.call(Unknown Source)
    	at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
    	at DataSource.invokeMethod(DataSource.groovy)
    	at DataSource$_run_closure3.doCall(DataSource.groovy:15)
           <snipped>
    The relevant datasource is:


    Code:
    environments {
    	development {
    		dataSource {
    			logSql = false
    			dbCreate = "create-drop" // one of 'create', 'create-drop','update'
    			dialect=org.hibernate.dialect.MySQL5InnoDBDialect
    			url = "jdbc:mysql://localhost:3306/plover_development?tcpKeepAlive=true"
    		}
    	}
    I am running mySQL 5.5.24 and the driver is mysql-connector-java:5.1.18. It is an older driver, but it is compatible with mySQL 5.5.

    Anyone else encountered a similar problem in the past?

  • #2
    Looks properly configured to me. What version of Grails? Any plugins installed that might bring in an older version of the Hibernate jar?

    Comment


    • #3
      I am using Grails 2.0.4. I also have trashed the workspace, and ivy cache. My plugins don't seem to be pulling another hibernate jar:


      Plug-ins you currently have installed are listed below:
      -------------------------------------------------------------
      cucumber 0.2.2 -- Cucumber Plugin
      drools-gorm 0.5.6 -- Drools Gorm
      geb 0.6.2 -- Geb integration for Grails
      hibernate 2.0.4 -- Hibernate for Grails
      janrain 1.1.0 -- Janrain Plugin
      jquery 1.7.1 -- JQuery for Grails
      jquery-ui 1.8.15 -- jQuery UI resources
      mail 1.0 -- Provides Mail support to a running Grails application
      nine-sixty-grid-system1.0 -- 960 Grid System CSS framework
      pusher 0.4 -- Pusher plugin
      rabbitmq 0.3.2 -- Rabbit MQ
      release 2.0.3 -- Release Plugin
      resources 1.1.6 -- Resources
      rest 0.7 -- REST client facilities
      rest-client-builder 1.0.2 -- REST Client Builder Plugin
      spring-security-core1.2.7.1 -- Spring Security Core Plugin
      svn 1.0.2 -- Subversion Plugin
      tagcloud 0.3 -- Tagcloud
      tomcat 2.0.4 -- Apache Tomcat plugin for Grails
      webxml 1.4.1 -- WebXmlConfig
      Something in STS preferences? This is an odd error to see (which usually means I did something really stupid).

      Comment


      • #4
        I'd try to work this out from the commandline to reduce the number of variables. Once it's ok there you can sync up STS by running Grails Tools | Refresh Dependencies.

        Try running 'grails clean' first - that's the first thing to do when you get weird errors like this. Probably won't help in this case though.

        The line number that it's complaining about is this one:

        Code:
        streamBindingLobTypes.add( CharacterArrayClobType.INSTANCE.getAlternatives().getStreamBindingType() );
        but that's fine in the 3.6.10 jar that Grails 2.0.4 uses. You might try running 'grails dependency-report' and opening up the report in target/dependency-report/index.html to see if there's something funky there.

        Comment


        • #5
          Oh my. It appears that another developer might have checked in some changes that setup a Hibernate conflict. If I am reading the dependency report correctly, it looks like there are dependencies on both hibernate-core ver. 3.6.10Final and hibernate-core ver. 3.3.2GA. And refreshing ivy-cache downloads both 3.6.10F and 3.3.4GA jars. I happen to have another machine without the most recent changes (migrating to a new development computer was when I encountered this issue) which builds and runs--and generates a rather different dependency report. drools persistance seems to be involved in some way. There is a thread discussing this possibility (https://community.jboss.org/thread/200488) and mentions JPA 2 as a requirement for drools persistance. I notice on the older revision that drools has no dependencies while the new revision seems to have dependencies on both releases of hibernate-core. <sigh>

          I may just roll back the most recent changes locally, rebuild the dependencies and run a new report to see if the conflicts are resolved. If they are, I will roll back his changes on github and toss the problem into his cubicle.

          [update] Did a rollback and still no success and the project is still requesting hibernate-core 3.3.4GA, but at least only one jar--3.6.10Final--is being downloaded and stored in ivy. This just makes no sense at all.
          Last edited by MikeTempleman; Jul 5th, 2012, 01:15 PM.

          Comment


          • #6
            So my hibernate-core is the right version (3.6.10 Final). Since this error occurs as datasource.groovy executed I cannot see how a .jar conflict could cause it because between my code in datasource.groovy declaring the dialect and the org.hibernate.dialect.Dialect code all I see on the stack is:


            Code:
            | Error Error executing script RunApp: INSTANCE
            java.lang.NoSuchFieldError: INSTANCE
                at org.hibernate.dialect.Dialect.<clinit>(Dialect.java:119)
                at java.lang.Class.forName0(Native Method)
                at java.lang.Class.forName(Class.java:169)
                at DataSource$_run_closure1_closure2_closure5.class$(DataSource.groovy)
                at DataSource$_run_closure1_closure2_closure5.$get$$class$org$hibernate$dialect$MySQLInnoDBDialect(DataSource.groovy)
                at DataSource$_run_closure1_closure2_closure5.doCall(DataSource.groovy:23)
            It appears this is supposed to setup the class object Dialect:

            Code:
             public abstract class Dialect {
            97  
            98      private static final Logger log = LoggerFactory.getLogger( Dialect.class );
            99  
            100     public static final String DEFAULT_BATCH_SIZE = "15";
            101     public static final String NO_BATCH = "0";
            
                
            Characters used for quoting SQL identifiers
            105 
            106     public static final String QUOTE = "`\"[";
            107     public static final String CLOSED_QUOTE = "`\"]";
            108 
            109     private static final Set<BasicType> streamBindingLobTypes = new HashSet<BasicType>();
            110 
            111     static {
            112         // Blobs
            113         streamBindingLobTypes.add( BlobType.INSTANCE.getAlternatives().getStreamBindingType() );
            114         streamBindingLobTypes.add( MaterializedBlobType.INSTANCE.getAlternatives().getStreamBindingType() );
            115         streamBindingLobTypes.add( WrappedMaterializedBlobType.INSTANCE.getAlternatives().getStreamBindingType() );
            116         // Clobs
            117         streamBindingLobTypes.add( ClobType.INSTANCE.getAlternatives().getStreamBindingType() );
            118         streamBindingLobTypes.add( MaterializedClobType.INSTANCE.getAlternatives().getStreamBindingType() );
            119         streamBindingLobTypes.add( CharacterArrayClobType.INSTANCE.getAlternatives().getStreamBindingType() );
            120         streamBindingLobTypes.add( PrimitiveCharacterArrayClobType.INSTANCE.getAlternatives().getStreamBindingType() );
            121         // TODO: shouldn't SerializableToBlobType be in this list???
            122     }
            So why would the dialect setup invocation fail on using the static variable INSTANCE of CharacterArrayClobType and not for any of the other types? This type is in hibernate-core 3.6.10.Final as well as the other basic types.

            38public class CharacterArrayClobType extends LobType<Character[]> {
            39 public static final CharacterArrayClobType INSTANCE = new CharacterArrayClobType();
            Last edited by MikeTempleman; Jul 5th, 2012, 08:37 PM.

            Comment


            • #7
              If you comment out the dialect specification it'll just fail later on since the Dialect class is eventually used by Grails and Hibernate. It has nothing to do with your setting - the static initializer in the Dialect class is referring to a non-existent field, so it has to be a jar issue.

              Create a simple app with no plugins other than what you get initially and configure DataSource.groovy like you have here and it will work fine.

              Comment


              • #8
                Good suggestion. I built a test application using mySQL and the MySQL5InnoDBDialect--it ran without a problem. I then added drools-gorm 0.5.6--which required the hibernate-core 3.3.2GA jar (evicted by the hibernate-core 3.6.10.Final) and got the exact same error when trying to run the test application.

                heh. So now that I have found the problem, fixing it maybe another matter entirely. JBoss just released drools 5.4 which may have been the source of this problem, I am not sure. I still don't understand why one machine has an entirely different dependency report than a clean machine.


                thanks a bunch for the feedback and helpful suggestions.

                Comment


                • #9
                  So I think I need to force grails to load the hibernate-core-3.3.2.GA.jar instead of the later 3.6.10.Final. Otherwise I will have to dive into drools-gorm plugin to see if I can upgrade it to the most recent release--something I am not prepared to do right now.

                  However, I don't seem to be able to force Grails to load the earlier version of hibernate-core. This:


                  excludes "hibernate-core-3.6.10.Final"

                  Doesn't work. Maybe because hibernate-core is loaded as part of grails 2.0.4. I don't know. Any suggestions?

                  Comment


                  • #10
                    It's doable but then Grails won't work since it's compiled with 3.6.10 and (as you've seen) it's not compatible with 3.3.2. Drools-GORM has to be upgraded, or you can use Grails 1.3.9 which uses Hibernate 3.3.1 (should be compatible with 3.3.2).

                    Comment


                    • #11
                      I would much prefer not to roll back to grails 1.3.9. We have a lot of code written under grails 2.0.x and I suspect that a major rollback like that would be very painful. otoh, after forking drools-gorm and looking at bringing it up to date, I find that the drools/jbpm/hibernate environments are rather different than assumed in drools-gorm so that could be just as much effort.

                      <sigh> already lost 3 days this week, which puts me at least a month behind schedule. I didn't need this extra aggravation...

                      Comment


                      • #12
                        It turns out that excluding hibernate-annotations prevents this particular problem. I don't know if any other problems remain because we just removed use of drools-gorm and reference drools jars directly.

                        Comment

                        Working...
                        X