Enumerated(String) Primary Key fetched as byte[]


We're migrating an app from EE6 to EE7 and Glassfish/Payara 4 mandates us to update Hibernate to a JPA2-compliant implementation. We still had Hibernate 3.6.10 previously and we used the good old Criteria API. We also have EJB3 and CDI in our legacy code, and the database is Derby 10.10 (dialect TenSeven used).

So we were compelled to bump to 4.3.11, and, facing the issue below, we tried with 5.0.2 without success.

One of the entities has an Enum(String) PK. It used to work well with Hibernate 3.6 as per :
public class Status {
private Organ organ;
private boolean active;

public Status() {}
public Status(Organ organ, boolean active) {
this.organ = organ;
this.active = active;

@GenericGenerator(name="assignedGen", strategy="assigned")
@Column(name="organ", length=30, nullable=false)
public Organ getOrgan() {
return organ;

@Column(name="active", nullable=false)
public boolean isActive() {
return active;
// and setters too

The enum itself being as simple an enum can be::
public enum Organ {

If I generate the DDL scripts, I get this, which is perfectly OK:
create table status (organ varchar(30) not null, active boolean not null, primary key (organ));

Now, when I launch the application, as soon as it fetches entities from this table, this exception is thrown:
*Caused by: org.apache.derby.client.am.ColumnTypeConversionException: An attempt was made to get a data value of type 'byte[]' from a data value of type 'VARCHAR'.
* at org.apache.derby.client.am.Cursor.coercionError(Unknown Source)
at org.apache.derby.client.am.Cursor.getBytes(Unknown Source)
... 124 more

2015-11-09T01:03:54.138+0100|Severe: javax.ejb.EJBException
at com.sun.ejb.containers.EJBContainerTransactionManager.processSystemException(EJBContainerTransactionManager.java:750)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:700)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:505)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2044)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:220)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy244.getAllStatus(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:434)
at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
at com.xxxxxxxxxxxxxxx.v2.core.common.CommonManager$712301675$Proxy$_$$_Weld$EnterpriseProxy$.getAllStatus(Unknown Source)
at com.xxxxxxxxxxxxxxx.v2.site.framework.ApplicationManager.reloadStatus(ApplicationManager.java:209)

Caused by: org.hibernate.exception.DataException: could not execute query
at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:52)
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
at org.hibernate.loader.Loader.doList(Loader.java:2614)
at org.hibernate.loader.Loader.doList(Loader.java:2594)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2423)
at org.hibernate.loader.Loader.list(Loader.java:2418)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:109)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1705)
at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:363)

Needless to say I also tried to remove the @GeneratedValue/@GenericGenerator lines to no avail.

Unless this behavior is mandated by the JPA spec, it looks to me we have a regression here.


Payara, Derby 10.10, JDK 1.8.0_60


Fabien Marsaud
November 16, 2015, 7:09 AM

Added a test case.
Whe testing it, be sure to upgrade jboss-logging in glassfish/payara if using Hibernate 5+

Fabien Marsaud
November 23, 2015, 2:33 PM

I have the feeling I missed something to have this issue considered at all.
I wish I could propose a pullreq but I won't have the time and Hibernate may be too complex for me.
I have a workaround anyway...

Fabien Marsaud
January 2, 2016, 9:44 PM

Updating the issue myself: following the forum discussion:

2.1.4 Primary Keys and Entity Identity


The primary key (or field or property of a composite primary key) should be one of the following types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date. In general, however, approximate numeric types (e.g., floating point types) should never be used in primary keys. Entities whose primary keys use types other than these will not be portable.


Si I added a numeric Id to the table. But the result was the same.
To be continued...

Steve Ebersole
February 28, 2016, 1:22 AM

Per JPA an identifier cannot be an @Enumerated

Fabien Marsaud
May 9, 2016, 9:29 PM

@Steve: right, but the problem remained at the time.

Just a heads up on that issue of mine:
This migration was not a priority so I let it rest for some time. Last Thursday I just updated all to Hibernate 5.1.0.Final and Payara, and everything worked perfectly. (Naturally as a prerequisite, one needs to update the jboss-logging jar + clean osgi cache on Payara on the one hand, and have up-to-date persistence.xml hibernate properties on the other hand - I'm writing them below for the record).

I have the feeling I was at the wrong place at the wrong time back in November...

The (probably always) working persistencde.xml




Fabien Marsaud

Fix versions






Suitable for new contributors


Requires Release Note


Pull Request




Affects versions