[GLASSFISH-16199] IllegalArgumentException: object is not an instance of declaring class - on a REST / EJB Service Created: 13/Mar/11  Updated: 29/Apr/13  Resolved: 26/Mar/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: V3, v3.0.1, 3.1
Fix Version/s: 3.1.1_b09

Type: Bug Priority: Major
Reporter: jraduget Assignee: Jakub Podlesak
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Attachments: File restEjb.war    
Issue Links:
depends on JERSEY-1813 Wrong handling method is used for EJB... Resolved
Tags: 3_1_1-approved, 3_2prd, jax-rs



I'm have the following error when deploying a JAX-RS / EJB service in a war or ear.

The exception : "java.lang.IllegalArgumentException: object is not an instance of declaring class"

Java code :

public interface Echo {

   String echo(String message);


@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
public class EchoImpl implements Echo {

   public String echo(@QueryParam("message") final String message) {
	return message;


public class RestResourcesApp extends Application {

   public Set<Class<?>> getClasses() {
	Set<Class<?>> s = new HashSet<Class<?>>();
	return s;



<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
	id="WebApp_ID" version="3.0">



works on tomcat 7.x, but failed on glassfish v3, V3.1

Please find attach war test case.

If you removed "implements Echo" in class EchoImpl , it will works


Comment by jraduget [ 13/Mar/11 ]

A precision: the error occurred not at deployment step, but when I test the rest service with this uri in a browser :


The full stack trace will be more convenient :

[#|2011-03-13T16:42:37.732+0100|SEVERE|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=29;_ThreadName=Thread-1;|The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:167)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:70)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:279)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:86)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:74)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1347)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1279)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1229)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1219)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:419)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:537)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:699)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)



Comment by Jason Lee [ 25/Mar/11 ]

Removing the rest-interface component, as it is unrelated to this issue. The rest-interface module is for issues with the GlassFish RESTful management interface.

Comment by Jakub Podlesak [ 30/Mar/11 ]

We work on a similar issue also with WLS guys.
To resolve this, we are going to

1) provide a hook in the resource method dispatcher logic
(will be reused by WLS, GF)
2) update the EJB integration layer in Jersey (GF specific)

Comment by Jakub Podlesak [ 03/Jun/11 ]

The plan is to have this fixed in Jersey 1.8. The fix should be available in the Jersey main trunk by June 17.

Comment by scatari [ 16/Jun/11 ]

Approved for 3.1.1. Please make sure to include "Fix in version" as "3.1.1_b09". Currently B09 is targeted for 06/23.

Comment by Jakub Podlesak [ 21/Jun/11 ]

Fixed in the Jersey main trunk, revision number 5119

Comment by ymenager [ 06/May/12 ]

I've just had that exact problem in glassfish 3.1.2, i thought this was supposed to be fixed in 3.1.1 ???

I've even downloaded the attached restEjb.war, and it fails in the exact same way

Comment by rherschke [ 26/Jun/12 ]

Please reopen this issue, due to it is not fixed and can reproduced in gf 3.1.2.

Comment by Jakub Podlesak [ 26/Jun/12 ]

This is a regression, as the app works fine with Jersey 1.8 in GlassFish 3.1.1
It is breaking again in Jersey 1.11 in GF 3.1.2

Comment by marina vatkina [ 26/Jun/12 ]

The EJB definition is not correct - see "4.9.7 Session Bean’s Business Interface" in the EJB 3.1 spec:

•The same business interface cannot be both a local and a remote business interface of the bean

Comment by rherschke [ 26/Jun/12 ]

Well, but this is not the reason for the error.

See http://www.adam-bien.com/roller/abien/entry/glassfish_jersey_exception_java_lang for a workaround. But sometimes, you have to expose your REST service as a remote session bean too, where the solution, Adam is suggesting in the url, will not fit.

Comment by marina vatkina [ 26/Jun/12 ]

If we would have a proper EJB validation during deployment, your application won't deploy. If you need to access your bean through a local and a remote view, you need to have 2 interfaces defined. Adam's example has a bean with a local view.

Comment by rherschke [ 26/Jun/12 ]

@marina vatkina:

You did not get the point:

(1) I did not give the example, attached to this issue
(2) I'm facing same problems with NO(!!!) Annotations (neither @Local nor @Remote) tagging the business interface
(3) I cannot tag the business interface due to it is in a third party dependency (well, could do this with aspectj but...)
(4) I know, that Adam's example use an @LocalBean annotation which will not fit in my scenario (as described before) with the requirement to have a Remote SLSB implementing the business interface and thats why the error occurs

I don't like to discuss about other's view of the specification nor about the correctness of others example.

I've written, that this issue is still reproducible in gf 3.1.2 esp. if there is no Annotation attached to the SLSB implementation nor the business interface.

So i'm very fine with Jakub's answer (which also leads to reopen this issue until another jersey version is available for gf 3.1.2).

Comment by Jakub Podlesak [ 02/Jul/12 ]

The regression should already be fixed in Jersey 1.13. Not sure yet, when this would get into GF. Most likely it will be included in GF 3.1.3.

Comment by Jakub Podlesak [ 26/Mar/13 ]

This has been fixed in Jersey 2.0-rc1, that has been integrated into the GF main trunk earlier today.

Comment by Jakub Podlesak [ 29/Apr/13 ]

The use case seems no longer supported by GF v4. The following error occurs when deploying the test web app:

+ asadmin deploy target/ejb-test-webapp.war
remote failure: Error occurred during deployment: Exception while deploying the app [ejb-test-webapp] : The interface org.glassfish.jersey.tests.ejb.resources.Echo cannot be both a local and a remote business interface. Please see server.log for more details.
Command deploy failed.
Generated at Sat Apr 18 21:33:48 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.