Community
Participate
Working Groups
Build Identifier: 2.2.0.v20101117-r8503 While EclipseLink processes entity classes using the static weaving processor it throws this error: The type [class java.lang.Long] for the attribute [id] on the entity class [class XXXXX] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface. Well, in fact Long IS serializable but it is because it extends java.lang.Number which in turn implements serializable. Looking into the latest eclipselink source code I find this: Class org.eclipse.persistence.internal.jpa.metadata.accessors.objects.MetadataClass: 150 public boolean extendsClass(String className) { 151 if (getName() == null) { 152 return className == null; 153 } 154 155 if (getName().equals(className)) { 156 return true; 157 } 158 159 if (getSuperclassName() == null) { 160 return false; 161 } 162 163 if (getSuperclassName().equals(className)) { 164 return true; 165 } 166 167 return getSuperclass().extendsClass(className); 168 } And you can see by yourself that there is no recursion and therefore it will always only find class that directly implement the Serializable interface and never through inheritance. Here is the full stack trace: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20101117-r8503): org.eclipse.persistence.exceptions.ValidationException Exception Description: The type [class java.lang.Long] for the attribute [id] on the entity class [class XXXXX] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface. at org.eclipse.persistence.exceptions.ValidationException.invalidTypeForSerializedAttribute(ValidationException.java:1088) at org.eclipse.persistence.internal.jpa.metadata.converters.SerializedMetadata.process(SerializedMetadata.java:86) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processSerialized(MappingAccessor.java:1664) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processJPAConverters(MappingAccessor.java:1447) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingConverter(MappingAccessor.java:1509) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingValueConverter(MappingAccessor.java:1527) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.BasicAccessor.process(BasicAccessor.java:372) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.IdAccessor.process(IdAccessor.java:83) at org.eclipse.persistence.internal.jpa.metadata.MetadataDescriptor.processMappingAccessors(MetadataDescriptor.java:1435) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.processMappingAccessors(ClassAccessor.java:1405) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processMappingAccessors(EntityAccessor.java:1061) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.process(EntityAccessor.java:601) at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage2(MetadataProject.java:1464) at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:483) at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:453) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildTransformer(StaticWeaveClassTransformer.java:165) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildClassTransformers(StaticWeaveClassTransformer.java:125) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.<init>(StaticWeaveClassTransformer.java:82) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.process(StaticWeaveProcessor.java:250) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.performWeaving(StaticWeaveProcessor.java:174) at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:131) at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:99) at org.glassfish.osgijpa.JPABundleProcessor.enhance(JPABundleProcessor.java:142) at org.glassfish.osgijpa.JPAExtender.bundleChanged(JPAExtender.java:93) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3710) at org.apache.felix.framework.Felix.installBundle(Felix.java:2628) at org.apache.felix.framework.Felix.installBundle(Felix.java:2424) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:129) at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:953) at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:872) at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:785) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:423) at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241) Reproducible: Always Steps to Reproduce: 1. Create an entity with an java.lang.Long attribute and make it implement Serializable 2. Let the class being "weaved" statically
I just debugged to actually see what's going wrong here and in although I realize your "solution" for recursion using "getSuperClass" it doesn't work here as the MetadataClass for "java.lang.Long" does not contain a superclass although it does extend "java.lang.Number", so I suspected something is wrong with the "org.eclipse.persistence.internal.libraries.asm.ClassReader" at first but then noticed that the ClassMetadataVisitor for "java.lang.Long" is called and does include the correct super class. But it is called way too late and I couldn't figure out why this happens. So the situation here is that several OSGi bundles can't be started because of this error and at some point when "java.lang.Long" is finally being "visited" the corresponding bundles deploy fine.
EclipseLink 2.1 was fine in this aspect.
Changed the summary to reflect what is the reason for this error. Further debugging revealed that during the "MetadataAsmFactory.buildClassMetadata()" call for "java.lang.Long" an IOException occurs saying "class not found" a MetadataClass gets created which only contains some very basic properties and no superclass as would be needed here. I should mention again that this is running inside GlassFish 3.1 b31 with Felix OSGi.
Closing this bug as it turned out to be an issue with the timing of glassfish JPA enhancement and bundle installation vs. resolving.
I had the same problem (2.1.2.v20101206-r8635) BUT it was related to missing FilePermission: 1. Security Manager was turned on: java.security.manager 2. I forgot to enable file permission: permission java.io.FilePermission "C:/development/jdk1.6.0_20/jre/lib/-", "read"; Now everything is running smooth again :-) (after 2 days of work ...)
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
