Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-11053

NoSuchMethodError from JPA on standalone Tomcat 6 startup

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Not version specific
    • Component/s: Configuration
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-4599Test Kuali Rice standalone server in Tomcat 6
      KULRICE-3436Rice Standalone server sometimes gets weird quartz related error from KCB during startup
      KULRICE-4990fixing log4j errors in rice on tomcat startup
      KULRICE-3897When Tomcat sessions are persisted in Rice, this can sometimes cause issues with Tomcat startup
      KULRICE-5124Tomcat 7 fixes for rice 2.0
      KULRICE-2950Standalone Rice server fails to startup when log4j file is not present
      KULRICE-1304JPA Migration
      KULRICE-7644CLONE - Unable to log in to ks-rice in standalone mode with ks-rice-1.2.2-M3
      KULRICE-2810Rice standalone server startup throws a CXF error
      KULRICE-4593Rice wont startup under Java 5
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Persistence Framework
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Running Tomcat 6 standalone, the following error has recently started to prevent initialization of krad-sampleapp.

      [EL Info]: 2013-10-21 05:46:02.794--ServerSession(1836365346)--EclipseLink, version: Eclipse Persistence Services - 2.5.1.v20130918-f2b9fc5
      [EL Info]: 2013-10-21 05:46:02.952--ServerSession(1836365346)--file:/C:/cygwin/opt/kuali/servers/tomcat/webapps/krad-dev/WEB-INF/lib/rice-krad-app-framework-2.4.0-M3-SNAPSHOT.jar_coreService logout successful
      [EL Severe]: 2013-10-21 05:46:02.962--ServerSession(1836365346)--java.lang.NoSuchMethodError: org.kuali.rice.krad.bo.Note._persistence_checkFetchedForSet(Ljava/lang/String;)V
              at org.kuali.rice.krad.bo.Note._persistence_set_noteText(Note.java)
              at org.kuali.rice.krad.bo.Note.setNoteText(Note.java:218)
              at org.kuali.rice.krad.bo.Note.<init>(Note.java:94)
              at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
              at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
              at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
              at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
              at java.lang.Class.newInstance(Class.java:374)
              at org.eclipse.persistence.descriptors.ClassDescriptor.preInitialize(ClassDescriptor.java:3975)
              at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:649)
              at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:632)
              at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.initializeDescriptors(DatabaseSessionImpl.java:568)
              at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:799)
              at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:743)
              at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:239)
              at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:685)
              at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:204)
              at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getMetamodel(EntityManagerFactoryDelegate.java:637)
              at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getMetamodel(EntityManagerFactoryImpl.java:548)
              at sun.reflect.GeneratedMethodAccessor851.invoke(Unknown Source)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:606)
              at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.invokeProxyMethod(AbstractEntityManagerFactoryBean.java:376)
              at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler.invoke(AbstractEntityManagerFactoryBean.java:519)
              at com.sun.proxy.$Proxy19.getMetamodel(Unknown Source)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:606)
              at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:177)
       
      

        Issue Links

          Activity

          Hide
          Mark Fyffe (Inactive) added a comment -

          Resolved in my local environment. See thread below:

          I’ve updated again, ran mvn clean install, and restarted my server – same results. Then I tried a clean checkout with no local modifications, and still see the weaver error. It seems to have become quite reproducible in my local environment. Note.class is first loaded within KRADSpringBeans.xml, as an import on NoteServiceImpl, and a log message added within a static initializer block appears among other JPA initialization methods. I am running Tomcat 6.0.37 on Windows 8 in a standalone configuration with only JDBC drivers and Spring instrumentation support added, but the error is also evident launching Tomcat from Eclipse. All seems to be set up as it should be, and unrelated to my local modifications.

          After a few hours spent tracking this down, however, I have found a solution: In order to support instrumentation in Tomcat, krad-sampleapp and rice-sampleapp include the following context.xml:

          <Context>
          <Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>
          </Context>

          This context will not work properly unless spring-instrument-tomcat-3.2.3.RELEASE.jar is present in CATALINA_BASE/lib. I noted, however, that krad-sampleapp also includes this library in WEB-INF/lib. The presence of the same .jar twice at two different levels in the classloader hierarchy is rare a good thing It is easy to envision a scenario where the class would be instrumented inconsistently by two different loaders. By changing this dependency to provided in krad-data/pom.xml and rebuilding, the jar no longer deploys with krad-sampleapp. With only one copy of the Tomcat instrumentation jar in the hierarchy, my server once again starts without encountering the issue.

          I’m not sure why it suddenly started to affect me over the weekend or why it didn’t affect rice-sampleapp, however. Judging by the lack of impact noted by others and lack of change to correlate to the problem, I suspect a timing issue, or possibly an environmental issue specific to standalone Tomcat.

          I created KULRICE-11053 and committed this POM change to address the issue. If this is not a correct solution, or if the change leads to other issues downstream please let me know!

          Best,
          Mark

          Show
          Mark Fyffe (Inactive) added a comment - Resolved in my local environment. See thread below: I’ve updated again, ran mvn clean install, and restarted my server – same results. Then I tried a clean checkout with no local modifications, and still see the weaver error. It seems to have become quite reproducible in my local environment. Note.class is first loaded within KRADSpringBeans.xml, as an import on NoteServiceImpl, and a log message added within a static initializer block appears among other JPA initialization methods. I am running Tomcat 6.0.37 on Windows 8 in a standalone configuration with only JDBC drivers and Spring instrumentation support added, but the error is also evident launching Tomcat from Eclipse. All seems to be set up as it should be, and unrelated to my local modifications. After a few hours spent tracking this down, however, I have found a solution: In order to support instrumentation in Tomcat, krad-sampleapp and rice-sampleapp include the following context.xml: <Context> <Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/> </Context> This context will not work properly unless spring-instrument-tomcat-3.2.3.RELEASE.jar is present in CATALINA_BASE/lib. I noted, however, that krad-sampleapp also includes this library in WEB-INF/lib. The presence of the same .jar twice at two different levels in the classloader hierarchy is rare a good thing It is easy to envision a scenario where the class would be instrumented inconsistently by two different loaders. By changing this dependency to provided in krad-data/pom.xml and rebuilding, the jar no longer deploys with krad-sampleapp. With only one copy of the Tomcat instrumentation jar in the hierarchy, my server once again starts without encountering the issue. I’m not sure why it suddenly started to affect me over the weekend or why it didn’t affect rice-sampleapp, however. Judging by the lack of impact noted by others and lack of change to correlate to the problem, I suspect a timing issue, or possibly an environmental issue specific to standalone Tomcat. I created KULRICE-11053 and committed this POM change to address the issue. If this is not a correct solution, or if the change leads to other issues downstream please let me know! Best, Mark
          Hide
          Erik Meade added a comment -

          Same NoSucehMethodError has shown up in CI IT Tests. See KULRICE-11067

          Show
          Erik Meade added a comment - Same NoSucehMethodError has shown up in CI IT Tests. See KULRICE-11067

            People

            • Assignee:
              Mark Fyffe (Inactive)
              Reporter:
              Mark Fyffe (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 hours
                2h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h

                  Structure Helper Panel