"java.lang.VerifyError"

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"java.lang.VerifyError"

lancedolan
Has anybody run into this before? I'm tempted to thing it's a defect in Sling 8.

I write a @Service for OSGI, and it has a @Reference to another service, such as a ResourceResolverFactory, and deploy it to Sling the same way I have for several years, and it fails to get the Reference, with the following:

Error during instantiation of the implementation object (java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
  Location:
    com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V @5: if_acmpne
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0x0000000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1    
)
java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
  Location:
    com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V @5: if_acmpne
  Reason:
    Expected stackmap frame at this location.
  Bytecode:
    0x0000000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1    

****************************
Steps to reproduce:

- Running on Java 8 HotSpot JVM
- Download latest Sling 8 from http://sling.apache.org/downloads.cgi. You can use either standalone or "Web Application," I've confirmed on both.
- Start the Sling server
- Write and Compile a simple OSGI bundle using the maven-bundle-plugin
- Include the following Servlet

@SlingServlet(
        paths = "/myservice/image",
        methods = {"GET" , "POST"})
public class ImageServlet extends SlingSafeMethodsServlet{

    @Reference
    ResourceResolverFactory resolverFactory;

    @Override
    protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/html");

        PrintWriter out = response.getWriter();

        out.println("

" + "HELLO WITH A  " + resolverFactory + " FROM SERVLET" + "

");

    }

}

You'll get the error on deployment of the bundle, and the servlet will not register, and you'll get a 404 when attempting to hit the servlet. If you comment out the @Reference annotation, so that Sling doesn't try to inject the ResourceResolverFactory, then the Servlet will register, but of course the resolverFactory will be null.

I also tested by writing my own *very* simple hello world service, and that gets the same java.lang.VerifyError on instantiation.

My best guess is that I need to use a different JVM version or some JVM arguments so that it doesn't do this verification??


Reply | Threaded
Open this post in threaded view
|

Re: "java.lang.VerifyError"

lancedolan
Sort of solved:

adding -noverify to the JVM arguments stops this error from occurring.

However, I don't fully understand the cause and I'm also nervous about forward compatibility... I wonder how this could prevent us from moving to future Java versions. It just seems like a bad smell that stable behaviour depends on an esoteric JVM flag.
Reply | Threaded
Open this post in threaded view
|

Re: "java.lang.VerifyError"

Steven Walters
This error is usually caused by an old version of ASM that is used for
writing the implementation of the bind/unbind methods of references if
such functions do not already exist.

This usually stems from the use of an old maven-scr-plugin, and
upgrading to a newer one will most usually fix this, or you can write
the java code for bind/unbind yourself (so they are not auto-generated
incorrectly).

I don't remember what all was in Sling8, so not sure if you could
migrate to the now preferred OSGi R6/DS 1.3 annotations instead...


On Tue, Jan 31, 2017 at 7:28 AM, lancedolan <[hidden email]> wrote:

> Sort of solved:
>
> adding -noverify to the JVM arguments stops this error from occurring.
>
> However, I don't fully understand the cause and I'm also nervous about
> forward compatibility... I wonder how this could prevent us from moving to
> future Java versions. It just seems like a bad smell that stable behaviour
> depends on an esoteric JVM flag.
>
>
>
> --
> View this message in context: http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp4070000p4070001.html
> Sent from the Sling - Users mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

Re: "java.lang.VerifyError"

lancedolan
That's the solution, thank you!

My maven-scr-plugin version had fallen badly out of date by re-building from an archetype... bumped to latest version and I no longer need the -noverify argument.

Thanks again :D