Issue opening in backoffice in Hybris 6.6

[Former Member]

I am getting below error while opening the backoffice

EVERE: Servlet.service() for servlet [zkLoader] in context with path [/backoffice] threw exception [Servlet execution threw an exception] with root cause java.lang.VerifyError: Instruction type does not match stack map Exception Details: Location: com/hybris/cockpitng/core/persistence/packaging/WidgetClassLoader.getResourceURL(Ljava/util/jar/JarFile;Ljava/util/zip/ZipEntry;)Ljava/net/URL; @15: new Reason: Type 'java/lang/String' (current frame, locals[0]) is not assignable to 'java/util/jar/JarFile' (stack map, locals[0]) Current Frame: bci: @15 flags: { } locals: { 'java/lang/String', 'java/util/zip/ZipEntry' } stack: { } Stackmap Frame: bci: @15 flags: { } locals: { 'java/util/jar/JarFile', 'java/util/zip/ZipEntry' } stack: { } Bytecode: 0x0000000: 2ab6 02a1 1261 b602 a599 0006 1261 4bbb 0x0000010: 0059 59bb 001e 59b7 001f 125a b600 212a 0x0000020: b600 54b6 0021 125b b600 212b b600 5cb6 0x0000030: 0021 b600 22b7 005d b04d b200 1cbb 001e 0x0000040: 59b7 001f 125e b600 212b b600 5cb6 0021 0x0000050: 125f b600 212a b600 54b6 0021 1260 b600 0x0000060: 21b6 0022 2cb9 0037 0300 01b0 Exception Handler Table: bci [15, 56] => handler: 57 Stackmap Table: same_frame(@15) same_locals_1_stack_item_frame(@57,Object[#50])

     at com.hybris.backoffice.cockpitng.modules.BackofficeLibraryHandler.getClassLoader(BackofficeLibraryHandler.java:348)
     at com.hybris.backoffice.cockpitng.modules.BackofficeLibraryHandler.afterDeploy(BackofficeLibraryHandler.java:98)
     at com.hybris.cockpitng.modules.core.impl.CockpitModuleComponentDefinitionService.doAfterDeploy(CockpitModuleComponentDefinitionService.java:185)
     at com.hybris.cockpitng.modules.core.impl.CockpitModuleComponentDefinitionService.fetchInModules(CockpitModuleComponentDefinitionService.java:161)
     at com.hybris.cockpitng.modules.core.impl.CockpitModuleComponentDefinitionService.fetchExternalWidgets(CockpitModuleComponentDefinitionService.java:10

[Former Member]

Maybe you compiled with some version of your libs and at runtime libs are not exactly the same

[abderzakeboufeta]

EDIT: The issue we had was indeed due to the version 7.1.5 of JRebel. I hope you were having the same: Their support team quickly answered to confirm that the bug only occurs on this version. Version 7.1.6 is to released around Jan. 6th . In the meantime, options are to downgrade top 7.1.4 or grab the nightly version.

Would you happen to use some kind of "hot-code replace" tooling ?

Some of our developers are having the same issue as yours. They're running JRebel (v7.1.5). Booting the server without JRebel happens to workaround the issue.

We're looking into the issue on our side, we'll share our findings if any!

[Former Member]

Thanks, that fixed it for me too. I was already getting mad...

[yury_bich]

I faced with the same issue. Thanks for posting details how to fix it