geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janko Heilgeist <geronimo-2...@dalighe.de>
Subject Re: Entity with generic base interface results in VerifyError
Date Thu, 20 Sep 2007 10:06:30 GMT
Hi again,

I tinkered around in my code yesterday and I think, I've narrowed down
the problem. Forget about my last mail. I am pretty sure, that the
exception about incompatible classes is just a result of broken
dependencies somewhere in my Maven build. Probably different versions of
 libraries used by stand-alone client and deployed JAR.

My main problem ist still the exception about a "wrong return type". I
moved the classes mentioned in my first mail to an Eclipse project and
tried a few things... The basic generic interface stays the same as in
my first mail:

public interface GenericEntity<PK extends Serializable> {
	PK getEntityId();
	void setEntityId();
}

For the Dummy interface I tried three different implementations, that
should lead to the same results:

(1)
public interface Dummy {
	Long getEntityId();
	void setEntityId(Long entityId);
}

(2)
public interface Dummy extends GenericEntity<Long> {
}

(3)
public interface Dummy extends GenericEntity<Long> {
	Long getEntityId();
	void setEntityId(Long entityId);
}

For the implementing class I tried two variations:

public class DummyImpl implements Dummy, Serializable {
	private Long entityId; // variation (A)
        private long entityId; // variation (B) with auto-boxing
	Long getEntityId() { return entityId; }
	void setEntityId(Long entityId) {
		this.entityId = entityId;
	}
}

I then compiled, deployed and executed the code with Java 1.5.0_12 and
Java 1.6.0_02. For variation (A) of the DummyImpl class the results
where rather boring:

*** interface (1) + variation (A), java 1.5 and java 6:
Everything works just fine!

*** interface (2)/(3) + variation (A), java 1.5 and java 6:
The EJB deploys correctly but during execution of the stand-alone client
I receive the known VerifyError because of a "wrong return type in
function" getEntityId(). See my first mail for the complete Stacktrace.

Things get more interesting with variation (B) of the DummyImpl class:

*** interface (1) + variation (B), java 1.5:
The EJB deploys successfully, but during execution of the client I
receive a warning, that getter and setter of the entityId violate some
requirements of OpenJPA. The warning is immediately followed by a NPE in
the enhancement code of OpenJPA. (See attachment trace_1_b.txt)

The warning says, that "Getters must return a single non-computed
field". I guess, that the auto-boxing violates this constraint. If this
is correct, then I would expect the same exception for interfaces (2)
and (3), but:

*** interface (2)/(3) + variation (B), java 1.5:
While executing the stand-alone process, OpenJPA parses the meta-data
successfully and tries to create the tables in the DB. However, he fails
to recognize the type of entityId and tries to create a table with a
primary key of type BLOB. This failes with a ReportingSQLException (see
strack trace in attachment trace_23_b.txt)

The experiments with variation (A) of the implementing class already
showed, that OpenJPA seems to fail due to the generic interface. The
ReportingSQLException in the last two cases further points to an
unrecognized return type of the getEntityId()-function. Reflection on
the DummyImpl-class returns two methods with the name getEntityId:

Serializable getEntityId(); // from GenericEntity
Long getEntityId(); // from either Dummy (1)/(3) or DummyImpl (2)

This is just a wild guess, but could it be, that OpenJPA's reflection
code takes the first appearance of the method and never discovers the
second one?

Regards, Janko


Janko Heilgeist wrote:
> Hi Jarek,
> 
> thanks for your help. I just compiled, deployed and tested the modified
> code. The previous VerifyError is now replaced by another exception (see
> surefire-report below), but I guess the problem is the same and it's
> just java 1.5's way of expressing it. Looks like David was right with
> his first guess, that the enhancement changes the SUID of the entity.
> 
> I already tried your code with a manually inserted serialVersionUID, but
> the result is identical.
> 
> If the enhancement changes the SUID, then I should be able to enhance
> the entities before deployment and have client and appserver use the
> same pre-enhanced jar, correct?
> 
> Regards, Janko
> 
> -------------------------------------------------------------------------------
> Test set: mypackage.client.DummyTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.143
> sec <<< FAILURE!
> testFoo(mypackage.client.DummyTest)  Time elapsed: 0.104 sec  <<< ERROR!
> javax.naming.NamingException: Cannot lookup
> '/generic-entity-ejb-1.0/DummyDAO/mypackage.dao.DummyDAORemote'. [Root
> exception is java.rmi.RemoteException: Cannot read the response from the
> server (OEJP/2.0) : org.apache.openejb.client.EJBMetaDataImpl; local
> class incompatible: stream classdesc serialVersionUID =
> -7734383756981201981, local class serialVersionUID =
> 2128092884552388429; nested exception is:
> 	java.io.InvalidClassException:
> org.apache.openejb.client.EJBMetaDataImpl; local class incompatible:
> stream classdesc serialVersionUID = -7734383756981201981, local class
> serialVersionUID = 2128092884552388429]
> 	at org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:205)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392)
> 	at mypackage.client.DummyTest.testFoo(DummyTest.java:26)
> Caused by: java.rmi.RemoteException: Cannot read the response from the
> server (OEJP/2.0) : org.apache.openejb.client.EJBMetaDataImpl; local
> class incompatible: stream classdesc serialVersionUID =
> -7734383756981201981, local class serialVersionUID =
> 2128092884552388429; nested exception is:
> 	java.io.InvalidClassException:
> org.apache.openejb.client.EJBMetaDataImpl; local class incompatible:
> stream classdesc serialVersionUID = -7734383756981201981, local class
> serialVersionUID = 2128092884552388429
> 	at org.apache.openejb.client.Client.processRequest(Client.java:197)
> 	at org.apache.openejb.client.Client.request(Client.java:43)
> 	at org.apache.openejb.client.JNDIContext.request(JNDIContext.java:74)
> 	at org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:199)
> 	... 28 more
> Caused by: java.io.InvalidClassException:
> org.apache.openejb.client.EJBMetaDataImpl; local class incompatible:
> stream classdesc serialVersionUID = -7734383756981201981, local class
> serialVersionUID = 2128092884552388429
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
> 	at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
> 	at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
> 	at
> org.apache.openejb.client.JNDIResponse.readExternal(JNDIResponse.java:64)
> 	at org.apache.openejb.client.Client.processRequest(Client.java:192)
> 	... 31 more
> 
> -------------------------------------------------------------------------------
> 
> 
> Jarek Gawor wrote:
>> Janko,
>> 
>> Try the attached sample. It's the sample you sent us just cleaned it
>> up a bit. Changed the compiler option to 1.5 and integrated the
>> DummyClient as a test. This deployed and worked fine for me - didn't
>> see any exceptions.
>> 
>> Jarek
>> 

Mime
View raw message