grabbit icon indicating copy to clipboard operation
grabbit copied to clipboard

Error activating bundle: "Error creating bean with name 'clientJobLauncher'"

Open fortman opened this issue 9 years ago • 4 comments

We are consistently getting this error on our production servers. I have tried restarting the Adobe instances, but the error is the same. We are not getting the error in lower environments, only production. I'm working to see if there are any differences between the environments, but so far I haven't found any. Here is the error.

20.07.2015 12:58:26.843 -0400 ERROR [SpringOsgiExtenderThread-6] org.springframework.osgi.extender.internal.activator.ContextLoaderListener Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=com.twcable.grabbit, config=osgibundle:/META-INF/spring/*.xml)) org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'clientJobLauncher' defined in URL [bundle://629.0:0/META-INF/spring/client-batch-job-context.xml]: Cannot resolve reference to bean 'clientJobRepository' while setting bean property 'jobRepository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'clientJobRepository' defined in URL [bundle://629.0:0/META-INF/spring/client-batch-job-context.xml]: Instantiation of bean failed; nested exception is java.lang.VerifyError: Stack map does not match the one at exception handler 54 Exception Details: Location: com/twcable/grabbit/spring/batch/repository/JcrJobRepositoryFactoryBean.getJobExecutionDao()Lorg/springframework/batch/core/repository/dao/JobExecutionDao; @54: dup Reason: Type top (current frame, locals[0]) is not assignable to 'com/twcable/grabbit/spring/batch/repository/JcrJobRepositoryFactoryBean' (stack map, locals[0]) Current Frame: bci: @52 flags: { } locals: { } stack: { 'java/lang/Throwable' } Stackmap Frame: bci: @54 flags: { } locals: { 'com/twcable/grabbit/spring/batch/repository/JcrJobRepositoryFactoryBean', '[Ljava/lang/Object;', 'java/lang/Object' } stack: { 'java/lang/Throwable' } Bytecode: 0000000: 03bd 0043 4c13 0172 1301 732a 12ea 1301 0000010: 742b b801 7a4d 2ab4 0062 014e 593a 0413 0000020: 0172 1301 732a 12ea 1301 742b 2c2d 1904 0000030: b801 7eb0 00bf 593a 0501 3a06 1301 7213 0000040: 0173 2a12 ea13 0174 2b2c 1905 1906 b801 0000050: 7ebf Exception Handler Table: bci [22, 54] => handler: 54 Stackmap Table: full_frame(@52,{},{Object[#100]}) full_frame(@54,{Object[#2],Object[#384],Object[#67]},{Object[#100]})

    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:329)
    at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:107)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)

fortman avatar Jul 20 '15 17:07 fortman

Hey @fortman , is there a possibility of a mismatch of Java version that built Grabbit which is deployed here v/s the Java version that the production servers are running on?

Looking at the VerifyError exception above, a version mismatch seems likely.

sagarsane avatar Jul 20 '15 19:07 sagarsane

@sagarsane I checked our content server vs our production server, and they have the same JRE. The content server (and others) are running fine. It just seems to be our production servers. I haven't had time to do a full audit for the differences in environments. I still plan on doing it at some point.

prod java.class.version 51.0 java.runtime.version 1.7.0_45-b18

content server java.class.version 51.0 java.runtime.version 1.7.0_45-b18

fortman avatar Jul 21 '15 16:07 fortman

Ah ok. Also, are you using a pre-built version of Grabbit from Bintray (https://bintray.com/twcable/aem/Grabbit/2.0.1/view#files) or are you using Jenkins internally to build latest master of Grabbit and deploying that?

If latter, it may be worthwhile checking if Jenkins is building Grabbit using Java 7 as well.

sagarsane avatar Jul 21 '15 20:07 sagarsane

Hey @fortman do you think we are good to close this one out at this point?

jbornemann avatar Jan 14 '16 18:01 jbornemann