Ok i have some additional info (hopefully!):
Without setting any access type (my current code base) and excluding, as advised by beikov, the Eclipse and m2e overheads, i renamed the unmatched getter to ‘getX’ and used the mvn command to clean and install and it failed as expected because of that unmatched getter probably:
java.lang.ClassCastException: Object of type 'TYPEA' can't be cast to CompositeTracker
Then i renamed the getter to ‘returnX’ and the mvn command failed too! So just renaming the getter does not fix the issue so most probably (?), the Eclipse and/or the m2e are playing a role in the previous erratic results.
So then i renamed ‘returnX’ to ‘getX’ and set all access types to FIELD for entity and embeddable classes. Now everything works fine using both environments: Eclipse or mvn command! as if somehow Eclipse and/or the m2e were corrupting the code (?). At least i hope this is the case and not one more erratic scenario. And may be in my case i had other unmatched getters elsewhere causing the problem.
So i am not sure @beikov that i can create a simple test case here apart from the known access type solution.
Anyway, after the successful compilation, when the server starts, i still have the error:
Caused by: java.lang.IllegalArgumentException: Cannot subclass primitive, array or final types: class com.enterprise.guide.app.core.place.model.transport.Airport
The Airport entity class is a class having only @Embedded fields and no unmatched getters (TransportPlace is an entity class without any field and extends other mappedsuperclasses or entities):
@Entity
@Access(AccessType.FIELD)
public final class Airport extends TransportPlace implements IAirport{
@Embedded
private EMBA embA;
@Embedded
private EMBB embB;
}
But even when i remove the final keywork for this class, other final classes with different models fail too. And if i decompile the Airport class, i can see that it has been enhanced.
And @beikov , about the debugging analysis, you said:
How can the class not be the root class but also not have subclasses.
The debugger gives for the Airport class:
bootDescriptor.getRootClass() is AbstractPlace which is the root class in my case
bootDescriptor is the Airport class
!bootDescriptor.hasSubclasses() is true as the Airport class is final.
So the Airport class is not the root class and does not have subclasses as it is final. no?
When you talk about :
the branch for enhanced entity classes
in
org.hibernate.metamodel.internal.EntityRepresentationStrategyPojoStandard#resolveProxyFactory
what do you mean? which condition is that ? The 1st that should return null or the 2nd that returns the byte buddy factory?