Comment 1 Michael OBrien 2009-03-06 11:01:21 EST

The APT tooling library work has been spun off into the separate enhancement bug# 267391.

Comment 2 Michael OBrien 2009-03-10 09:34:56 EDT

Created attachment 128191 [details]
jpa metamodel blank implementation class templates (no headers, just function stubs)

This implementation template class will be used to fill out the function stubs.
It matches the UML class hierachy diagram in the following wiki location.

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#Public_API

Comment 3 Michael OBrien 2009-03-10 10:08:46 EDT

Created attachment 128197 [details]
JPA Metamodel and Criteria API interfaces 20090302

Comment 4 Michael OBrien 2009-03-10 10:09:33 EDT

Created attachment 128198 [details]
JPA Metamodel and Criteria API Implementation UML class diagram against 20090302 version

Comment 5 Michael OBrien 2009-03-11 11:18:14 EDT

Created attachment 128381 [details]
JPA Metamodel API Implementation UML class diagram (after merge with Doug's Implementation)

This UML diagram is a result of a merge with Doug's existing larger implementation start for the Metamodel API.
I will be posting updates as I work out the final form, fill in the rest of the stub methods and complete the initial test cases.

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#Metamodel_Implementation

Comment 6 Michael OBrien 2009-03-12 13:32:30 EDT

Work is precluded by bug# 246126 related work for 24-48 hours.

Comment 7 Michael OBrien 2009-03-27 09:25:05 EDT

Created attachment 130103 [details]
Metamodel MappedSuperclass design POC review 1 (non-production code)

Guy, Gordon,
   Here is a preliminary POC for MappedSuperclass support in the Metamodel API.
   This is not to be checked in - I am distributing it for early design review.
   I have only implemented support for Basic mappings so far (an @Id annotation for example), I am proceeding with the remaining mappings, functionality and Embeddable support while we review this particular design direction that we worked out recently.
   
>Summary:
1) During the existing transient JPA MetaData processing - we add a step during MappedSuperclass discovery to add a new empty RelationalDescriptor to the core Project for any mapped superclass.
  EntityAccessor.discoverMappedSuperclassesAndInheritanceParents()

2) Later when the MappedSuperclassAccessor is processed and mappings are copied to the inheriting subclass - we add a step to also add this mapping to our new RelationalDescriptor on the project set
  BasicAccessor.process()
  Note: we will need to extend process for all other accessor types in the same way

3) When a Metamodel instance is requested via an EM or EMF call - we build the Metamodel from all the descriptors - but we add the extra step of building the list of MappedSuperclass instances from the Set of RelationalDescriptors on the project.
  MetamodelImpl
    private java.util.Map<Class, MappedSuperclassTypeImpl<?>> mappedSuperclasses;


>Example model:
@MappedSuperclass
public class Person {
    @Id
    @SequenceGenerator(name = "EL_SEQUENCE_PERSON", sequenceName = "EL_PERSON_SEQ", allocationSize = 25)
    @GeneratedValue(generator = "EL_SEQUENCE_PERSON")
    private Integer id;

and the inheriting class:
@Entity
@Table(name = "EL_CUSTOMER")
public class Customer extends Person {


>Output:
_Metamodel mappedSuperclassType key: class org.eclipse.persistence.example.jpa.server.business.Person value: MappedSuperclassTypeImpl@20508445 [descriptor: RelationalDescriptor(null --> []), mappedSuperclass: class org.eclipse.persistence.example.jpa.server.business.Person]
__Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[id-->EL_CUSTOMER.ID] (should be PERSON.ID)


>Todo:
- I need to create a clone of the mapping that points to the mappedSuperclass descriptor instead of the inheriting subclass
- need to override equals and hashcode (to check by (mappedSuperclass.getClass()) on a new MappedSuperclassHashSet subclass of HashSet or ConcurrentHashSet (TBD)
- I am updating the design doc (it is 2

Comment 8 Michael OBrien 2009-04-06 09:26:51 EDT

Created attachment 130984 [details]
Metamodel MappedSuperclass design POC review 2 (non-production code) - rev 3831

Comment 9 Michael OBrien 2009-04-06 09:27:28 EDT

Created attachment 130985 [details]
JPA Metamodel API Implementation UML class diagram

Comment 10 Doug Clarke 2009-04-08 15:09:23 EDT

Changing priority to P@ since JPA 2.0 features are required for the 2.0 release

Comment 11 Michael OBrien 2009-04-14 14:49:51 EDT

Created attachment 131824 [details]
eclipselink jpa build (.MANIFEST.MF) - generated build.xml change

This patch containing the JPA .MANIFEST.MF build change is the result of a build.xml modification or manual modification of the manifest - which method to use is TBD after we finish our Orbit migration.

Comment 12 Michael OBrien 2009-04-14 15:16:30 EDT

Created attachment 131835 [details]
eclipselink jpa build (.MANIFEST.MF) - generated build.xml change

build and generated manifest changes for JPA and javax.persistence targets

Comment 13 Michael OBrien 2009-04-19 23:27:45 EDT

Returning to this work late monday 20080420 after undoing patch #9 (build changes) and merging with the same and additional changes in rev# 3980 from bug# 272748.

Comment 14 Michael OBrien 2009-05-11 17:02:46 EDT

Created attachment 135222 [details]
EclipseLink jpa build patch (rev 4047)

The following patches are for review of a part implementation of the JPA 2.0 Metamodel API.
>The remaining work items will be listed at the end of the test and core patches.

Comment 15 Michael OBrien 2009-05-12 09:07:04 EDT

Created attachment 135336 [details]
Eclipselink jpa test patch (off of 4047)

Comment 16 Michael OBrien 2009-05-12 09:08:29 EDT

Created attachment 135338 [details]
Eclipselink JPA criteria.queryBuilder stub patch (off of 4047)

Comment 17 Michael OBrien 2009-05-12 09:10:53 EDT

Created attachment 135339 [details]
Eclipselink JPA metamodel (partial implementation) patch (off of 4047)

Everyone,
    For community reference, here is a partial implementation of the new Metamodel API as part of the JPA 2.0 JSR-317 specification (Ch 5 and 6.6) - this version extends Doug's initial implementation framework and specification checkin for bug# 272748.  It follows ongoing reviews by Gordon, Guy and Doug.
    This partial version may be added to trunk with a posted SVN rev# - however the latest partial patches are for review and code sharing so that the separate Criteria API work can begin to sync with what is done here so far.
    The final checkin including review and outstanding work items below should be occur shortly after 25 May (I am out of the office in 2 days for 6 days from 14-22 May).

    http://bugs.eclipse.org/266912
    Based on rev# 4047

    The implementation is functional with part of EntityTypeImpl and ManagedTypeImpl functioning.  I am in the middle of finishing mappedSuperclass hierarchy work to enable ManagedTypeImpl superType functionality that all getDeclared*() functions require.  Our current native model does not store the mappedSuperclass that defines an inherited mapping - we can either search up the hierarchy tree on metamodel construction and find the new mappedSuperclass pseudo-descriptor we have created or modify the native model with a backpointer to the owning (java) superclass - this 2nd method was suggested by Doug in april but I only just now (2 days ago) fully understand the use case because it is required for getDeclared*() functionality.
    I am also in the middle of switching over the internal map of mappedSuperclass objects to a set with equals/hashCode identity overrides.

    Pending work:
-----------------
>- remove all System.out runtime printouts and breakpoints
>- finish all javadocs
>- finish all mappings support for MappedSuperclass functionality - currently only BasicAccessor support is added
-- TODO: verify all of OneToOneAccessor, ManyToOneAccessor, OneToManyAccessor, ManyToManyAccessor, EmbeddedAccessor
-- TODO: Optionally verify and support TransientAccessor, EmbeddedIdAccessor
-- No changes required yet to VariableOneToOneAccessor for abstract hierarchy support (not in spec)

>-(Part of MappedSuperclass implementation)
-- finish Set and equals()/hashCode() changes from last MappedSuperclass code review
-- implement no-clone-copy of mapping changes in MappedSuperclass code in BasicAccessor
-- finish ManagedType.superType assignment - keyed on mappedSuperclass implementation
-- finish all getDeclared*() calls that require checks based on ManagedType.superType
-- finish rest of non-type and non-declared get*() calls
-- finish all get*Id
-- finish all get*Version
-- complete CORE embeddable support
-- complete TEST embeddable support (including table generation)
-- complete CORE ManyToMany support
-- complete TEST ManyToMany support (including table generation)

>- finish and expand exception handling
-- more extensive parameterized generics testing with variable types is required
-- All IllegalArgumentExceptions for wrong name or type
- verify all toString() code
- expand test suite to include near TCK-level function and exception testing

    thank you
    /michael

Comment 18 Michael OBrien 2009-05-12 09:22:54 EDT

>currently merging with SVN rev 4162 including the large 4119 and 4126 transactions
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4162

Comment 19 Michael OBrien 2009-05-28 15:08:12 EDT

Created attachment 137539 [details]
Eclipselink JPA criteria.queryBuilder stub patch (off of 4350)

Comment 20 Michael OBrien 2009-05-28 15:25:51 EDT

Created attachment 137542 [details]
Eclipselink JPA metamodel (partial implementation) patch (off of 4350) 

This patch has been refactored to match the spec from 16 May 2009

Comment 21 Michael OBrien 2009-05-28 17:11:58 EDT

Created attachment 137557 [details]
Eclipselink jpa test patch (off of 4350)

Comment 22 Michael OBrien 2009-05-28 17:14:23 EDT

A first snapshot of a partial implementation of the Metamodel API for JPA 2.0 has been checked in under the following transaction.  Details on what is working and what is pending are in the link.

http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4353

This 4353 checkin only includes the implementation change - the testing suite and model patch will be checked in tomorrow.

Comment 23 Michael OBrien 2009-05-29 09:22:00 EDT

>Test configuration patch off of 4350 has been checked in under rev# 4357

http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4357

Comment 24 Michael OBrien 2009-05-29 15:29:16 EDT

>Test results Oracle 11 db, IBM J9 JVM
JPA LRG
    [junit] Tests run: 1202, Failures: 0, Errors: 0, Time elapsed: 1,634.646 sec
Core LRG
    [junit] Tests run: 6706, Failures: 0, Errors: 14, Time elapsed: 4,288.759 sec

Clean older 4352 view (same 0,14 after a db schema clean)
    [junit] Tests run: 6706, Failures: 0, Errors: 14, Time elapsed: 2,599.136 sec

Comment 25 Michael OBrien 2009-06-03 15:38:30 EDT

Created attachment 138191 [details]
JPA MetadataProject 20090603 review changes

Changes as a result of a code review by Guy

Comment 26 Michael OBrien 2009-06-04 10:27:47 EDT

Created attachment 138289 [details]
emf closed should throw IllegalStateException patch

Comment 27 Michael OBrien 2009-06-04 11:35:12 EDT

>See rev 4415
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4415

emf closed should throw IllegalStateException patch (1.98 KB, patch) 
2009-06-04 10:27 -0400, Michael OBrien  no flags  Details | Diff  
https://bugs.eclipse.org/bugs/attachment.cgi?id=138289&action=diff

>See rev 4416
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4416

JPA MetadataProject 20090603 review changes (7.23 KB, patch) 
2009-06-03 15:38 -0400, Michael OBrien  no flags  Details | Diff  
https://bugs.eclipse.org/bugs/attachment.cgi?id=138191&action=diff

Code reviewed by Guy

Comment 28 Michael OBrien 2009-06-12 09:28:40 EDT

Created attachment 139023 [details]
metamodel jpa implementation for mappedSuperclass descriptors (code developed with Guy and Gordon)

Comment 29 Michael OBrien 2009-06-12 10:19:27 EDT

Created attachment 139029 [details]
metamodel jpa implementation for mappedSuperclass descriptors (code developed with Guy and Gordon) - includes MetadataProject

Comment 30 Michael OBrien 2009-06-12 10:26:20 EDT

Created attachment 139030 [details]
metamodel jpa implementation for mappedSuperclass descriptors (code developed with Guy and Gordon) - includes MetadataProject

Comment 31 Michael OBrien 2009-06-12 10:43:36 EDT

Created attachment 139033 [details]
metamodel jpa implementation for mappedSuperclass descriptors (code developed with Guy and Gordon) - includes MetadataProject

Comment 32 Michael OBrien 2009-06-12 12:20:50 EDT

Created attachment 139042 [details]
test launch 199 from 100 classpath fix for post rev 4441 changes - reviewed by Tom

Comment 33 Michael OBrien 2009-06-12 12:26:37 EDT

>see rev 4480 for test launch changes
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4480

Comment 34 Michael OBrien 2009-06-12 13:00:17 EDT

Created attachment 139046 [details]
metamodel jpa implementation for mappedSuperclass descriptors (code developed with Guy and Gordon) - includes MetadataProject

Comment 35 Michael OBrien 2009-06-18 07:47:13 EDT

Created attachment 139534 [details]
Use Map keyed on metadataClass for mappedSuperclass descripto

Discussed this with James who suggested we move away from a hashCode/equals override when using a Set

Comment 36 Michael OBrien 2009-06-18 09:33:52 EDT

>see the following rev done in parallel with the accessor/metadataProject refactor that is in progress

http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4519

266912: Use a Map keyed on MetadataClass instead of overriding equals/hashCode for MappedSuperclass RelationalDescriptors
Suggested by and discussed with James
https://bugs.eclipse.org/bugs/attachment.cgi?id=139534&action=diff
- we may merge Project.mappedSuperclassDescriptors with Project.descriptors in the future
  to gain query and SessionCustomizer functionality on mappedSuperclasses
- The key is Object instead of MetadataClass so that we do not intruduce a Core-->JPA dependency
- The value may be ClassDescriptor in the future, for now we use a concrete RelationalDescriptor that matches what the accessors use
- Use of a HashMap will enforce identity based on the MetadataClass but we still require a contains(key) check
  because we do not want a put(key,value) to overwrite a descriptor that already contains mappings
  as we do 3 passes during metadata processing
- Our custom metamodel processing for mappedSuperclasses in the next transaction should be done in the normal initialize() and not treated specially
  This raises the issue of whether MappedSuperclasses should be treated as real descriptors (minus actually going to the database)

Comment 37 Michael OBrien 2009-06-23 22:56:55 EDT

Created attachment 139943 [details]
Preview patch for mappedSuperclass accessor processing (all models in JPA regression testing browser predeploy ok)

>There is a single failure on multiple table PK support (see issues 29 and 30) that must be resolved first in a 2nd patch.

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_29:_20090622:_Multiple_Table_PK_support_for_MappedSuperclasses
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_30:_20090623:_BasicMap_Parameterized_Generic_return_type_cannot_be_the_Void_class

Comment 38 Michael OBrien 2009-06-23 22:59:44 EDT

The patch above is an interrim patch for review - as all regression JPA models now pass predeploy().  I need to fix the multiple PK table failure most likely surrounding EntityAccessor.processInheritance() in addMultipleTableKeyFields.

Comment 39 Michael OBrien 2009-06-24 10:06:01 EDT

Created attachment 139984 [details]
JPA changes in support of MappedSuperclass descriptor processing - non production code

Comment 40 Michael OBrien 2009-06-24 10:52:36 EDT

>Working the following issue related to the above patch
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_28:_20090622:_Composite_PK_support_for_MappedSuperclasses


>see DI 28: 20090622: Composite PK support for MappedSuperclasses
The following exception is not occurring because of our change to add extra processing for MappedSuperclasses in processStage2, it happens in the use case where a composite key contains a mappedSuperclass and is inherited by a normal Entity. 
RelationalDescriptor(org.eclipse.persistence.testing.models.jpa.xml.inherited.BeerConsumer --> [DatabaseTable(__METAMODEL_RESERVED_IN_MEM_ONLY_TABLE_NAME), DatabaseTable(CMP3_XML_CONSUMER)]) 

We should not be initializing the new mappedSuperclass descriptor in this composite PK case.

entity	EntityAccessor  (id=44)	
  m_className	"org.eclipse.persistence.testing.models.jpa.xml.inherited.ExpertBeerConsumer" (id=93)	
  m_descriptor	MetadataDescriptor  (id=66)	
    m_inheritanceRootDescriptor	MetadataDescriptor  (id=68)	
      m_descriptor	RelationalDescriptor  (id=131)	
        javaClassName	"org.eclipse.persistence.testing.models.jpa.xml.inherited.BeerConsumer" (id=70)	
        primaryKeyFields	ArrayList<E>  (id=177)	
          elementData	Object[2]  (id=256)	
            [0]	DatabaseField  (id=258)	
              name	"__PK_METAMODEL_RESERVED_IN_MEM_ONLY_FIELD_NAME" (id=260)	
              qualifiedName	"__PK_METAMODEL_RESERVED_IN_MEM_ONLY_FIELD_NAME" (id=260)	
public void processStage2() {
        // 266912: process mappedSuperclasses without going to the database
        for(MappedSuperclassAccessor msAccessor : m_mappedSuperclassAccessors.values()) {
            if(!msAccessor.isProcessed()) {               
                msAccessor.processMetamodelDescriptor();    
            }
        }
 
        for (EntityAccessor entity : getEntityAccessors()) {
            // If the accessor hasn't been processed yet, then process it. An
            // EntityAccessor may get fast tracked if it is an inheritance
            // parent.
            if (! entity.isProcessed()) {
-->here          entity.process();

Comment 41 Michael OBrien 2009-06-24 11:48:08 EDT

Created attachment 139999 [details]
JPA changes in support of MappedSuperclass descriptor processing - JPA suite passing

>The JPA FieldAccess suite is passing now with some extra relaxation on validation for MappedSuperclass Descriptors when they are part of composite FK's

TEST MODEL NAME: (JUnit test): fieldaccess
Errors: (failures): 0
Fatal Errors: (errors): 0
Passed: 211
Total Tests: 211

ObjectBuilder
    public void initializePrimaryKey(AbstractSession session) throws DescriptorException {
                    //if(!primaryKeyField.getName().equals(MetadataConstants.MAPPED_SUPERCLASS_RESERVED_PK_NAME)) { // TODO: remove JPA dependency
                    if(!primaryKeyField.getName().equals("__PK_METAMODEL_RESERVED_IN_MEM_ONLY_FIELD_NAME")) { // TODO: remove JPA dependency
                      throw DescriptorException.noMappingForPrimaryKey(primaryKeyField, this.descriptor);
                    }

Comment 42 Michael OBrien 2009-06-24 13:40:25 EDT

20090624:1400

Code Review prep notes for
https://bugs.eclipse.org/bugs/attachment.cgi?id=139999&action=diff

>Prep Before:
1) move constants from MetadataConstants (JPA) to AbstractSessionLog (Core)
2) Javadoc on superclass ClassAccessor.hasMappedSuperclasses()
3) remove/merge three if statements in EmbeddableAccessor:170
4) EntityAccessor:1417
   verify no validation for
	if(!getDescriptor().isPkClassDefinedOnMappedSuperclass()) {
   Javadoc on hasMappedSuperclasses()
5) MappedSuperclassAccessor
   remove getIdClass() as it is no longer used by MetadataProject.addMappedSuperclassAccessor
6) DirectCollectionAccessor
   151: verify workaround for no referenceClass in mappedSuperclass descriptor
   311: verify we do not need to processMappingValueConverter() for mappedSuperclass descriptors
   because currently I do not process in 311 but I do in 344
   Note: either one must be modified
7) ElementCollectionAccessor
   415: verify we are good to override a generic Type definition (IE: T) to Void in getReferenceClass()
8) MappingAccessor
   456: verify we can skip compositePrimaryKey JoinColumn Metadata processing when
	if(!descriptor.hasDescriptorReservedForMetamodelAsParent()) {
   519: verify Void parameterized generics override
   568: verify getReferenceName override for MappedSuperclass where we return "" empty string - need to refactor this
   1271: verify early return with null - avoiding a NPE when getting the name for a mapkey
9) MetadataAnnotatedElement
   240: verify Void parameterized generics override
10) InheritanceMetadata
   81: no change to accessor.processInheritancePrimaryKeyJoinColumns();
11) MetadataDescriptor
   285: TODO: workaround for empty table names may need to be higher than in addForeignKeyFieldForMultipleTable
   872: verify early return with empty DatabaseTable is ok for getPrimaryTable() - same as for aggregateDescriptor
if(hasDescriptorReservedForMetamodelAsParent()) { 
                 return new DatabaseTable(); 

12) MetadataProject
   972: verify secondary check of our custom map of MappedSuperclass descriptors for entities
   TODO: this is where we may have a problem that causes most of the issue with multiple PK's above
   By picking up our MS descriptors here - we end up causing them to be processed by initialize() during login() which we do not want


Performance:
1) Verify that any of the if() checks do not affect performance - as in they are in a tight loop

>During review:

Comment 43 Michael OBrien 2009-06-25 00:29:10 EDT

Created attachment 140059 [details]
JPA changes in support of MappedSuperclass descriptor processing - with accessor reload (comment cleanup required)

>1) turns out that the descriptor on the accessor was being switched on getProject() in MetadataProject.
>I was not reloading the accessor to get my own instance - I was using the instance on the project
>which containted a real Entity descriptor on my MappedSuperclassAccessor.
>I also was not setting the back pointer accessor.getDescriptor().setClassAccessor(accessor);
From
 getProject().addMappedSuperclassAccessor(metadataClass, accessor));
To
 getProject().addMappedSuperclassAccessor(metadataClass, reloadMappedSuperclass(accessor,  new MetadataDescriptor(metadataClass)));

>2) also, where we resolve a parameterized generic to Void or String - we still have an issue unless we relax validation for any descriptor with a mapped superclass in its heirarchy.
The validation step complains that String does not implement Serializable - but it does.

>Exception Description: The type [class java.lang.String] for the attribute [null] on the entity class [class org.eclipse.persistence.testing.models.jpa.xml.inherited.RatedBeerConsumer] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface.

Comment 44 Michael OBrien 2009-06-25 11:38:09 EDT

Created attachment 140117 [details]
JPA changes in support of MappedSuperclass descriptor processing

>Modifications
The following two lines were modified in MetadataProject.addMappedSuperclassAccessor() so that we use Metadata processing instead of setting the tableName/Id directly on the classDescriptor
            descriptor.setPrimaryTable(new DatabaseTable(MetadataConstants.MAPPED_SUPERCLASS_RESERVED_TABLE_NAME));
            descriptor.getClassDescriptor().addPrimaryKeyFieldName(MetadataConstants.MAPPED_SUPERCLASS_RESERVED_PK_NAME);            


>Embeddable Issue
Without the owning Descriptor relaxation check in EmbeddableAccessor.process()
We get the following exception

                    // check that the accessor does not inherit from a MappedSuperclass                    
                    if(!getDescriptor().getClassAccessor().isMappedSuperclass() &&
-->                     !owningDescriptor.getClassAccessor().isMappedSuperclass()) {
                            throw ValidationException.conflictingAccessTypeForEmbeddable(getJavaClass(), usesPropertyAccess(), owningDescriptor.getJavaClass(), owningDescriptor.getClassAccessor().usesPropertyAccess());
                    }


Caused by: Exception [EclipseLink-7245] (Eclipse Persistence Services - 2.0.0.qualifier): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The *metadata-less* embeddable class [class org.eclipse.persistence.testing.models.jpa.inherited.Accredidation] is used in entity classes with conflicting access-types.  Its property access flag is set to [true]. It is being embedded in a [class org.eclipse.persistence.testing.models.jpa.inherited.RatedBeerConsumer] with property access flag set to: [false]. This is not allowed as this may result in inconsistent mappings of the embeddable class in different points of use. This problem can be corrected in two ways: 1. Provide metadata on class [class org.eclipse.persistence.testing.models.jpa.inherited.Accredidation] that allows the access type to be determined. 2. Ensure all users of class [class org.eclipse.persistence.testing.models.jpa.inherited.Accredidation] have the same access type.
	at org.eclipse.persistence.exceptions.ValidationException.conflictingAccessTypeForEmbeddable(ValidationException.java:2358)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EmbeddableAccessor.process(EmbeddableAccessor.java:181)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataDescriptor.processAccessors(MetadataDescriptor.java:1197)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.processAccessors(ClassAccessor.java:774)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.MappedSuperclassAccessor.processMetamodelDescriptor(MappedSuperclassAccessor.java:1165)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage2(MetadataProject.java:1119)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:456)
	at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:297)
	at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:839)

Comment 45 Michael OBrien 2009-06-25 14:48:55 EDT

Created attachment 140145 [details]
JPA changes in support of MappedSuperclass descriptor processing - against rev#4531 before sync on #4567

>JPA suite results will be 0,0 after sync with 4567 (previously were 7,18)
    [junit] Tests run: 1219, Failures: 4, Errors: 1, Time elapsed: 1,710.907 sec

Comment 46 Michael OBrien 2009-06-25 14:59:43 EDT

>Code Review: Guy and I went over the new sections and changed the following....
- remove extra check && descriptor.getClassAccessor() in MetadataAnnotatedElement.getReferenceFromGeneric
   changed order of the following calls in MetadataProject.addMappedSuperclassAccessor() to...
        accessor.getDescriptor().setClassAccessor(accessor);
        accessor.addAccessors();
- order the new functions inside the file - do not append at the end
- For parameterized generics workaround change String type back to Void

Comment 47 Michael OBrien 2009-06-26 12:04:06 EDT

Created attachment 140256 [details]
JPA metamodel testing changes

>ongoing test model changes in sync with
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#Mapped_Superclass_Test_Model

Comment 48 Michael OBrien 2009-06-26 12:05:14 EDT

Created attachment 140258 [details]
JPA metamodel implementation changes (ongoing)

Comment 49 Michael OBrien 2009-06-26 12:09:07 EDT

Created attachment 140259 [details]
JPA Metadata and Core Native API changes in support of Metamodel accessor processing (off rev# 4567)

>This (baseline rev# 4567) JPA and Core patch (non Metamodel API) details changes in support of adding accessor (essentially MappedSuperclass) processing for the Metamodel API

266912: Metamodel API for JPA 2.0 - Implement MappedSuperclass accessor processing to generate non-DB descriptors
http://bugs.eclipse.org/266912 
https://bugs.eclipse.org/bugs/attachment.cgi?id=140145&action=diff 

Modifications: All JPA metadata API modifications in support of Metamodel API (mostly for MappedSuperclasses)
- MappedSuperclass accessors are transiently stored on the MetadataProject 
  so they can also be processed into descriptors - this Map is later discarded 
  along with the MetadataProject when predeploy is finished.
- (new) MappedSuperclass descriptors are persisted during preprocessing by storing them in a Map on the non-JPA native Project - 
  as the MetadataProject is transient.  Later the Metamodel picks up all descriptors 
  (including MappedSuperclass versions) and creates ManagedTypes for them.
- general accessor processing reloads accessor from XML to avoid sharing instances (clones)
  deprecates BasicAccessor specific processing
- added validation handler for EmbeddableAccessor, MapKey in MappingAccessor
- added validation handlers for parameterized generics during accessor processing (defaults to Void type)
  MetadataAnnotatedElement, MappingAccessor, ElementCollectionAccessor, 
  SerializedMetadata workaround for our Void (or String) workaround above
 
In collaboration with: Guy
Reviewed by: Guy, Gordon 
JPA LRG ok 

>checkin to trunk will follow

Comment 50 Michael OBrien 2009-06-26 16:55:46 EDT

>We are getting 5 errors on the JPA regression suite that represent 2 problems
1) IndirectMap references are not passing compare checks
Why? It turns out that the key:value pairs for the Hashtable in the IndirectMap is BigDecimal:Integer - where it should be Integer:Integer.
This most likely is due to our Void.class override on unresolvable parameterized generic types like Map<X, Y>

>For example by debugging 2 different Eclipse views (unmodified, modified) we see the followng different Map signatures

>good
[null, 1=1, 2=2, 3=3, null, null, null]
secondObjectMap	IndirectMap  (id=83)	
	delegate	IndirectMap  (id=303)	
		delegate	Hashtable<K,V>  (id=6877)	
			count	3	
			entrySet	Collections$SynchronizedSet<E>  (id=6898)	
				c	Hashtable$EntrySet  (id=6907)	
					this$0	Hashtable<K,V>  (id=6877)	
						count	3	
						entrySet	Collections$SynchronizedSet<E>  (id=6898)	
						keySet	null	
						loadFactor	0.75	
						modCount	4	
						table	Hashtable$Entry<K,V>[7]  (id=6900)	
							[0]	null	
							[1]	Hashtable$Entry<K,V>  (id=6963)	
								hash	1	
								key	Integer  (id=6971)	
								next	null	
								value	Integer  (id=6972)	

>bad

[null, null, 3=3, 1=1, null, null, 2=2]
secondObjectMap	IndirectMap  (id=467)	
	delegate	IndirectMap  (id=476)	
		delegate	Hashtable<K,V>  (id=485)	
			count	3	
			entrySet	Collections$SynchronizedSet<E>  (id=490)	
			table	Hashtable$Entry<K,V>[7]  (id=492)	
				[0]	null	
				[1]	null	
				[2]	Hashtable$Entry<K,V>  (id=495)	
					hash	93	
					key	BigDecimal  (id=503)	
					next	null	
					value	Integer  (id=505)



2) exceptions are not thrown as expected for ordering - investigating

Comment 51 Michael OBrien 2009-06-26 17:02:27 EDT

>stacktrace of 1)

Thread [Thread-3] (Suspended)	
	Hashtable<K,V>.get(Object) line: 335	
	IndirectMap.get(Object) line: 303	
	IndirectMap.get(Object) line: 303	
	DirectMapContainerPolicy.compareContainers(Object, Object) line: 200	
	DirectMapMapping.compareObjects(Object, Object, AbstractSession) line: 267	
	ObjectBuilder.compareObjects(Object, Object, AbstractSession) line: 1584	
	ServerSession(AbstractSession).compareObjects(Object, Object) line: 686	
	InheritedModelJunitTest.testCreateNoviceBeerConsumer() line: 405	

Comment 52 Michael OBrien 2009-06-26 17:03:57 EDT

>Fix is to use Integer.class instead of Void.class for MappingAccessor MS defaults

    public MetadataClass getMapKeyReferenceClass() {
...
            // 266912: We do not currently handle resolution of the generic type when inherited from a parent MappedSuperclasses
            if(this.getClassAccessor().isMappedSuperclass()) {
                return new MetadataClass(this.getMetadataFactory(), Integer.class);//Void.class);


>With this change a HashTable.get(Object) passes equality on our subclassing IndirectMap

Comment 53 Michael OBrien 2009-06-26 23:49:39 EDT

We are now at 0,2 from 5,2
    [junit] Tests run: 1237, Failures: 0, Errors: 2, Time elapsed: 1,147.313 sec

Comment 54 Michael OBrien 2009-06-29 09:10:01 EDT

>See DirectMapContainerPolicy and ObjectBuilder.compare()
>If we use [Object] as our parameterized value in private Map<Y, Z> awards; we end up with only 4 failures on our Map tests

    [junit] Tests run: 1237, Failures: 4, Errors: 0, Time elapsed: 1,180.375 sec

Comment 55 Michael OBrien 2009-06-29 11:23:14 EDT

Created attachment 140393 [details]
JPA Metadata and Core Native API changes in support of Metamodel accessor processing (off rev# 4567)

    I am getting 0,0 on the JPA tests with a single additional change from friday on MappingAccessor - we were previously getting errors on the "inherited" test suite.
    [junit] Tests run: 1237, Failures: 0, Errors: 0, Time elapsed: 1,203.828 sec

>Map Issue solved:
------------------
    The patch from friday causes 2-4 errors depending on whether we defaulted to a Void(results in BigInteger) or Object type on a Map<X,Y> on a mappedSuperclass that inherits from Class<T> - where we are unable to determine T.
    The workaround is to try loading the class only when we are on a mappedSuperclass descriptor - if the class T is not found and a ValidationException is thrown then we default to Void in this specific case.

When we get a ValidationException from
    MetadataHelper.getClassForName(referenceClass.getName(), getMetadataFactory().getLoader());
We do
    return new MetadataClass(this.getMetadataFactory(), Void.class);


    There may be a better way to determine whether the type is a parameterized generic or not, we may want to investigate this - for now catching the validation exception is working fine.

The only change to the patch on the bug is.

>old https://bugs.eclipse.org/bugs/attachment.cgi?id=140259&action=diff
    public MetadataClass getMapKeyReferenceClass() {
        if (isMapAccessor()) {
            MetadataClass referenceClass = getAccessibleObject().getMapKeyClass(getDescriptor());
       
            if (referenceClass == null) {
                throw ValidationException.unableToDetermineMapKeyClass(getAttributeName(), getJavaClass());
            }
       
            // 266912: We do not currently handle resolution of the generic type when inherited from a parent MappedSuperclasses
            if(this.getClassAccessor().isMappedSuperclass()) {
                // default to Void
-->             return new MetadataClass(this.getMetadataFactory(), Void.class);
            }
            return referenceClass;
        } else {
            return getMetadataFactory().getClassMetadata(void.class.getName());
        }
    }

>new
    public MetadataClass getMapKeyReferenceClass() {
        if (isMapAccessor()) {
            MetadataClass referenceClass = getAccessibleObject().getMapKeyClass(getDescriptor());
       
            if (referenceClass == null) {
                throw ValidationException.unableToDetermineMapKeyClass(getAttributeName(), getJavaClass());
            }
       
            /**
             * 266912:  Use of parameterized generic types like Map<X,Y> inherits from class<T> in a MappedSuperclass field
             * will cause referencing issues - as in we are unable to determine the correct type for T.
             * A workaround for this is to detect when we are in this state and return a standard top level class.
             * An invalid class will be of the form MetadataClass.m_name="T"
             */
            if(this.getClassAccessor().isMappedSuperclass()) {
                // Determine whether we are directly referencing a class or using a parameterized generic reference
                // by tying to load the class and catching any validationException
                try {
>                   MetadataHelper.getClassForName(referenceClass.getName(), getMetadataFactory().getLoader());
                } catch (ValidationException exception) {
                    // default to Void
>                   return new MetadataClass(this.getMetadataFactory(), Void.class);
                }                         
            }
            return referenceClass;
        } else {
            return getMetadataFactory().getClassMetadata(void.class.getName());
        }
    }

Comment 56 Michael OBrien 2009-06-29 15:38:29 EDT

Created attachment 140424 [details]
JPA Metadata and Core Native API changes in support of Metamodel accessor processing (off rev# 4567)

>This patch is ready for committing, JPA tests are 0,0
    The only differences from the last patch is
       - addition of a MetatadaDescriptor.isMappedSuperclass() instead of using a getDescriptor().getClassAccessor().isMappedSuperclass() by clients
       - more detailed commenting around the MappedAccessor.getMapKeyReferenceClass():519 change.
          To summarize why we are using the getClassForName() check here?  When the referenceType is not a valid concrete java type like String or a user defined type in the classpath - we default to Void - usually in the case of something like "class T".

        - To expand on the discussion we had in our meeting this morning on the failures we were seeing on friday.
          These failures were due to the fact that I was defaulting to Void in all MappedSuperclass cases for MappingAccessor (some String and Integer cases).  Now I only override with Void when we are parameterized for MappedSuperclasses == less cases.


    thank you
    /michael

Comment 57 Michael OBrien 2009-06-30 10:53:01 EDT

Created attachment 140506 [details]
JPA Metadata, Core Native, JPA Metamodel, Tests full patch for rev# 4587

>Consolidated and reviewed patch has comment changes only from previous one - matches the SVN checkin

Comment 58 Michael OBrien 2009-06-30 11:49:15 EDT

>see rev# 4587
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4587

266912: JPA Metadata API changes in support of the Metamodel API implementation involving Map, ElementCollection and Embeddable types on MappedSuperclass descriptors
https://bugs.eclipse.org/bugs/attachment.cgi?id=140506&action=diff
In Collaboration with: Guy
Reviewed by: Guy, Gordon
Testing: 1.6.0_05-b13
JPA tests:    [junit] Tests run: 1237, Failures: 0, Errors: 0, Time elapsed: 1,163.406 sec
Core tests:   [junit] Tests run: 8731, Failures: 0, Errors: 14, Time elapsed: 1,872.078 sec (known 14 unrelated issues)

Comment 59 Michael OBrien 2009-07-03 09:26:28 EDT

Created attachment 140775 [details]
JPA Metamodel Implementation - ongoing - prep for API work

Comment 60 Michael OBrien 2009-07-06 10:26:23 EDT

Created attachment 140868 [details]
IdentifiableTypeImpl and getSingularAttributes() changes for ManagedTypeImpl

Comment 61 Michael OBrien 2009-07-06 10:29:08 EDT

>Support for use of javaClass to set the IdentifiableType.superType hierarchy is in bug# 282518

Comment 62 Michael OBrien 2009-07-06 10:58:49 EDT

Created attachment 140872 [details]
remove @Override annotations until the function hierarchy is set (eclipse IDE warning/error settings may differ)

Some @Override annotations were not allowing the build to complile on some IDE's (thank you Tom) depending on the error level.  I have removed the broken ones for getBindableJavaType() and others until the function call hierarchy is set.

Comment 63 Michael OBrien 2009-07-07 11:02:58 EDT

Created attachment 140970 [details]
Specification Bindable interface javadoc change (rev 4616)

>See rev# 4616

Comment 64 Michael OBrien 2009-07-07 11:31:19 EDT

Created attachment 140973 [details]
Specification Bindable interface javadoc change (rev 4618)

SINGULAR_ATTRIBUTE from SINGLE_ATTRIBUTE

Comment 65 Michael OBrien 2009-07-08 16:34:59 EDT

Created attachment 141134 [details]
javax.persistence.metamodel javadoc adjustments from 20090702 spec jar

Comment 66 Michael OBrien 2009-07-08 16:36:23 EDT

Created attachment 141135 [details]
metamodel ongoing API updates - see design issues 34,35,38,40

>The following design issue changes are in this patch
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_34:_20090707:_Temporary_CNFE_when_loading_Metamodel_Impl_class
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_35:_20090707:_Where_to_initialize_IdentifiableTypeImpl.supertype
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_38:_20090708:_OneToOne_Set_defaults_to_IndirectList
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_40:_20090708:_Type_hierarchy_numbers_are_missing_MappedSuperclass_types
- Fix issue where the elementType:Type on PluralAttributeType was always being set to BasicTypeImpl - it now is set to one of Entity|Embeddable|MappedSuperclass TypeImpl as well

>Implemented
- getBindableJavaType
    public Attribute<X, ?> getAttribute(String attributeName) {
    public CollectionAttribute<? super X, ?> getCollection(String name) {
    public <E> CollectionAttribute<? super X, E> getCollection(String name, Class<E> elementType) {
    public Set<PluralAttribute<? super X, ?, ?>> getCollections() {
    public ListAttribute<? super X, ?> getList(String name) {
    public <E> ListAttribute<? super X, E> getList(String name, Class<E> elementType) {
    public MapAttribute<? super X, ?, ?> getMap(String name) {
    public SetAttribute<? super X, ?> getSet(String name) {
    public <E> SetAttribute<? super X, E> getSet(String name, Class<E> elementType) {

>Testing (13 failures are unrelated residual schema issues)
    [junit] Tests run: 1247, Failures: 0, Errors: 13, Time elapsed: 670.581 sec

Comment 67 Michael OBrien 2009-07-08 17:01:06 EDT

>Ongoing implementation snapshot
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4629
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4630

Comment 68 Michael OBrien 2009-07-09 17:09:37 EDT

Created attachment 141245 [details]
metamodel ongoing implementation (IllegalArgumentException spec handlers for missing and invalid types)

Comment 69 Michael OBrien 2009-07-10 09:57:29 EDT

>266912: Ongoing metamodel API implementation updates 
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4643
https://bugs.eclipse.org/bugs/attachment.cgi?id=141245&action=diff 
>The following design issue changes are in this patch 
1) AttributeImpl.isAttribute() is no longer required - removed 
2) supertype handling for top-level entities and superclasses 
3) IllegalArgumentException spec handlers for missing and invalid types) 
  With variant test cases for invalid attribute types 
4) Start of declared functionality pertaining to the Identifiable parts (non-Embeddable, non-Basic) 

>Testing 
   [junit] Tests run: 1247, Failures: 0, Errors: 0, Time elapsed: 1,178.782 sec 

Comment 70 Michael OBrien 2009-07-10 11:58:04 EDT

Created attachment 141313 [details]
metamodel change for SingularAttribute.getType to not use mapping.getAttributeClassification

	It seems that OneToOneMapping returns null for the way I was getting the java class for SingularAttribute types.
	I changed the code to match my PluralAttribute

DatabaseMapping.java:432
    /**
     * PUBLIC:
     * The classification type for the attribute this mapping represents
     */
    public Class getAttributeClassification() {
        return null;
    }

SingularAttributeImpl
From:
    public Class<T> getBindableJavaType() {
        // In SingularAttribute our BindableType is SINGLE_ATTRIBUTE - return the java type of the entity
        return this.getJavaType();
Which called the superclass
    public Class<T> getJavaType() {
        return getMapping().getAttributeClassification(); // returns null for OneToManyMapping
    }

To:
    public Class<T> getBindableJavaType() {
        // In SingularAttribute our BindableType is SINGLE_ATTRIBUTE - return the java type of the entity
        return this.elementType.getJavaType();

Comment 71 Michael OBrien 2009-07-10 12:40:57 EDT

Created attachment 141316 [details]
Adjust BasicType processing to handle non-Entity Java types as part of Attribute.getType() 

Adjust BasicType processing to handle non-Entity Java types as part of Attribute.getType() and specifically SingularAttribute.getBindableJavaType, set the appropriate elementType based on the mapping type.

Comment 72 Michael OBrien 2009-07-10 12:43:32 EDT

>IdentifiableType changes in the above patch should be ignored - they are in mid implemenatation and will not be checked in.

Comment 73 Michael OBrien 2009-07-13 23:19:43 EDT

Created attachment 141476 [details]
Draft implementation of getDeclared*() functionality - prior to code review cleanup, optimization and final testing

>Draft Implementation of getDeclared*() functionality - prior to code review cleanup, optimization and final testing
    public Set<Attribute<X, ?>> getDeclaredAttributes() 
    public Set<PluralAttribute<X, ?, ?>> getDeclaredCollections() 
    public Set<SingularAttribute<X, ?>> getDeclaredSingularAttributes() 
    public Attribute<X, ?> getDeclaredAttribute(String name)
    public ListAttribute<X, ?> getDeclaredList(String name) 
    public <E> ListAttribute<X, E> getDeclaredList(String name, Class<E> elementType) 
    public CollectionAttribute<X, ?> getDeclaredCollection(String name) 
    public <E> CollectionAttribute<X, E> getDeclaredCollection(String name, Class<E> elementType) 
    public SetAttribute<X, ?> getDeclaredSet(String name) 
    public <E> SetAttribute<X, E> getDeclaredSet(String name, Class<E> elementType) 
    public MapAttribute<X, ?, ?> getDeclaredMap(String name) 
    public <K, V> MapAttribute<X, K, V> getDeclaredMap(String name, Class<K> keyType, Class<V> valueType) 
    public SingularAttribute<X, ?> getDeclaredSingularAttribute(String name) 
    public <Y> SingularAttribute<X, Y> getDeclaredSingularAttribute(String name, Class<Y> type)

Comment 74 Michael OBrien 2009-07-14 14:21:47 EDT

Created attachment 141554 [details]
Draft implementation of getDeclared*() functionality - prior to code review cleanup, optimization and final testing

>See future rev# 4659
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4659

Comment 75 Michael OBrien 2009-07-14 16:18:48 EDT

>correction - see rev 4661 for getDeclared*() functions
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4661

>Code review: ongoing - see patch cycle

>Testing  JPA (See MetamodelMetamodelTest.java) - no issues
before 4654 sync
    [junit] Tests run: 1251, Failures: 0, Errors: 0, Time elapsed: 1,473.952 sec
after 4654 sync (before the larger 4657)
    [junit] Tests run: 1251, Failures: 0, Errors: 0, Time elapsed: 1,840.963 sec
After 4657 - 4,1 failures were reviewed and are unrelated to my changes (I had no merge conflicts as well)
    [junit] Tests run: 1251, Failures: 4, Errors: 1, Time elapsed: 1,485.078 sec
After schema refresh (same unrelated failures testCreateNewSocialClubsWithMembers, testValidateSocialClub1Members, testValidateSocialClub2Members, testValidateSocialClub3Members, testSpecialAssassinOptimisticLocking-NPE)
    [junit] Tests run: 1251, Failures: 4, Errors: 1, Time elapsed: 928.822 sec
Just in case I did not rebuild test model jars via >ant
    [junit] Tests run: 1251, Failures: 4, Errors: 1, Time elapsed: 1,615.951 sec

Comment 76 Michael OBrien 2009-07-17 08:31:03 EDT

Created attachment 141875 [details]
IdentifiableType.getIdType (without testing for when CMP3Policy is null - composite PK)

Comment 77 Michael OBrien 2009-07-21 09:44:19 EDT

>Getting a NPE on initialization type creation for Map types (Map handling is not fully tested/implemented yet)
>Verify the getKeyType or getElementClass calls for null returns and post handlers.

When the NPE occurs,
line 53 is:
 keyType = managedType.getMetamodel().getType(policy.getKeyType().getClass());

and policy.getKeyType() is null.  The rest of the objects are:
  managedType: ManagedTypeImpl[RelationalDescriptor(org.eclipse.persistence.testing.models.jpa.inherited.BeerConsumer --> [DatabaseTable(CMP3_CONSUMER)])]    managedType.getMetamodel(): org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl@1b0eb2c
  policy: MappedKeyMapContainerPolicy(class java.util.Hashtable)
  policy.getKeyType(): null 

upfront, on the em.getQueryBuilder() call:

java.lang.NullPointerException
   at org.eclipse.persistence.internal.jpa.metamodel.MapAttributeImpl.<init>(MapAttributeImpl.java:53)
   at org.eclipse.persistence.internal.jpa.metamodel.ManagedTypeImpl.initialize(ManagedTypeImpl.java:903)
   at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.initialize(MetamodelImpl.java:229)
   at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.<init>(MetamodelImpl.java:85)
   at org.eclipse.persistence.internal.jpa.metamodel.MetamodelImpl.<init>(MetamodelImpl.java:90)
   at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getMetamodel(EntityManagerFactoryImpl.java:416)
   at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getQueryBuilder(EntityManagerFactoryImpl.java:398)
   at org.eclipse.persistence.internal.jpa.EntityManagerImpl.getQueryBuilder(EntityManagerImpl.java:1974)
   at org.eclipse.persistence.testing.tests.jpa.criteria.JUnitJPQLSimpleTestSuite.baseTestCase(JUnitJPQLSimpleTestSuite.java:347)

Comment 78 Michael OBrien 2009-07-21 10:52:19 EDT

>implementing DI 48
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_48:_20090721:_Implement_Map_support

Comment 79 Michael OBrien 2009-07-21 11:42:41 EDT

>For the object model where there is a PK on the mappedSuperclass of the owning entity there is no NPE issue but I am getting the class twice in error.
>The thing to note here is that "key" means PK not the k:key of the Map<K,v>
The key is
	private java.lang.Integer org.eclipse.persistence.testing.models.jpa.metamodel.Person.id


@Entity(name="HardwareDesignerMetamodel")
@Table(name="CMP3_MM_HWDESIGNER")
public class HardwareDesigner extends Designer implements java.io.Serializable{
    // The M:1 side is the owning side
    @ManyToOne(fetch=EAGER)//LAZY)
    @JoinTable(name="CMP3_MM_MANUF_MM_HWDES_MAP", 
            joinColumns = @JoinColumn(name="DESIGNER_MAP_ID"), 
            inverseJoinColumns =@JoinColumn(name="MANUF_ID"))   
    private Manufacturer mappedEmployer;
    

@Entity(name="ManufacturerMetamodel")
@Table(name="CMP3_MM_MANUF")
public class Manufacturer extends Corporation implements java.io.Serializable{
    // If a JoinTable with a JoinColumn is used - then we need a mappedBy on the inverse side here
    @OneToMany(cascade=ALL, mappedBy="mappedEmployer")
    private Map<String, HardwareDesigner> hardwareDesignersMap = new HashMap<String, HardwareDesigner>();

>and associated relational model join table
    public static TableDefinition buildMANUFACTURER_HARDWAREDESIGNER_MAP_JOINTable() {
        TableDefinition table = new TableDefinition();
        table.setName("CMP3_MM_MANUF_MM_HWDES_MAP");

        FieldDefinition field1 = new FieldDefinition();
        field1.setName("MANUF_ID");
        field1.setTypeName("NUMERIC");
        field1.setSize(15);
        field1.setShouldAllowNull(false);
        field1.setIsPrimaryKey(false);
        field1.setUnique(false);
        field1.setIsIdentity(false);
        field1.setForeignKeyFieldName("CMP3_MM_MANUF.PERSON_ID");
        table.addField(field1);        

        FieldDefinition field2 = new FieldDefinition();
        field2.setName("DESIGNER_MAP_ID");
        field2.setTypeName("NUMERIC");
        field2.setSize(15);
        field2.setShouldAllowNull(false);
        field2.setIsPrimaryKey(false);
        field2.setUnique(false);
        field2.setIsIdentity(false);
        field2.setForeignKeyFieldName("CMP3_MM_HWDESIGNER.PERSON_ID");
        table.addField(field2);        

        return table;
    }

>We pass through metamodel type creation without a NPE but the Class for getType() is wrong


Thread [Thread-3] (Suspended)	
	MapContainerPolicy.getKeyType() line: 360	
	MapAttributeImpl<X,K,V>.<init>(ManagedTypeImpl<X>, CollectionMapping) line: 53	
	EntityTypeImpl<X>(ManagedTypeImpl<X>).initialize() line: 903	
	MetamodelImpl.initialize() line: 229	
	MetamodelImpl.<init>(DatabaseSession) line: 85	
	MetamodelImpl.<init>(EntityManagerFactory) line: 90	
	EntityManagerFactoryImpl.getMetamodel() line: 416	
	EntityManagerImpl.getMetamodel() line: 1991	
	MetamodelMetamodelTest.testImplementation() line: 415	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	MetamodelMetamodelTest(TestCase).runTest() line: 168	
	MetamodelMetamodelTest(TestCase).runBare() line: 134	
	MetamodelMetamodelTest(JUnitTestCase).runBare() line: 379	
	TestResult$1.protect() line: 110	
	TestResult.runProtected(Test, Protectable) line: 128	
	TestResult.run(TestCase) line: 113	
	MetamodelMetamodelTest(TestCase).run(TestResult) line: 124	
	TestExecutor.execute(Test) line: 248	
	TestExecutor.runTest(Test) line: 671	
	SynchronizedTestExecutor.run() line: 61	

policy	MapContainerPolicy  (id=104)	
	cloneMethod	null	
	constructor	Constructor<T>  (id=109)	
	containerClass	Class<T> (org.eclipse.persistence.indirection.IndirectMap) (id=111)	
	containerClassName	"org.eclipse.persistence.indirection.IndirectMap" (id=112)	
	elementClass	Class<T> (org.eclipse.persistence.testing.models.jpa.metamodel.HardwareDesigner) (id=115)	
	elementClassName	"org.eclipse.persistence.testing.models.jpa.metamodel.HardwareDesigner" (id=117)	
	elementDescriptor	RelationalDescriptor  (id=118)	
	keyField	Field  (id=126)	
		annotations	byte[60]  (id=133)	
		clazz	Class<T> (org.eclipse.persistence.testing.models.jpa.metamodel.Person) (id=135)	
		type	Class<T> (java.lang.Integer) (id=143)	
	keyMethod	null	
	keyName	"id" (id=121)	

>getType(Class) should not be creating a type for java.lang.Class
type	BasicTypeImpl<X>  (id=150)	
	javaClass	Class<T> (java.lang.Class) (id=82)	

>I should be doing something like the following to handle when there is no PK and not gettting the class of a class
        MapContainerPolicy policy = (MapContainerPolicy) mapping.getContainerPolicy();
        Object policyKeyType = policy.getKeyType(); // both cases return a Class<?>
        if(null == policyKeyType) {
            // no key type, use elementClass  - test case required
            this.keyType = managedType.getMetamodel().getType(policy.getElementClass());
        } else {
            Type<?> keyType = managedType.getMetamodel().getType((Class)policyKeyType);
            this.keyType = (Type<K>) keyType;
        }

>which results in a BasicType<Integer>
keyType	BasicTypeImpl<X>  (id=88)	
	javaClass	Class<T> (java.lang.Integer) (id=82)	

Comment 80 Michael OBrien 2009-07-21 13:33:51 EDT

Created attachment 142158 [details]
metamodel patch for issues 47 (getIdType) and 48 (Map support)

>See issues 
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_47:_20090715:_Implement_IdentifiableType.getIdType.28.29_for_composite_keys
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_48:_20090721:_Implement_Map_support
>extended test case required for 48 where there is no PK on the owning entity

Comment 81 Michael OBrien 2009-07-22 17:03:52 EDT

Created attachment 142324 [details]
metamodel patch for issues 47 (getIdType) and 48 (Map support) including IdClass support

Comment 82 Michael OBrien 2009-07-23 11:32:23 EDT

>See partial @IdClass support in rev# 4710
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4710
>for
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_48:_20090721:_Implement_Map_support 

Comment 83 Michael OBrien 2009-07-27 16:23:28 EDT

>All new JPA 2.0 code modifications or issues are categorized as enhancement until the JPA 2.0 RI is released.

Comment 84 Michael OBrien 2009-07-29 10:42:57 EDT

Created attachment 142896 [details]
DI:52 enh 284877 ManagedType.hasDeclaredAttribute() unoptimized recursive changes

See design issue 52

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_52:_20090728:_JPA_2:_Implement_recursive_ManagedType.getDeclared.2A_algorithm_to_differentiate_by_IdentifiableType

Comment 85 Michael OBrien 2009-07-29 12:20:03 EDT

>See rev# 4754
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4754

Comment 86 Michael OBrien 2009-07-29 14:37:59 EDT

>See new Design Issue 53 after discussion with Shaun: we need to verify that we handle inherited fields from non-JPA classes mapped via XML (with no @Entity or @MappedSuperclass annotation)
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_53:_20090729:_Verify_that_inheritied_non-JPA_class_mappings_are_handled_by_the_Metamodel

Comment 87 Michael OBrien 2009-07-30 16:29:32 EDT

Created attachment 143085 [details]
metamodel impl patch for DI 47.48 and 50 (before LRG testing) some collection mapping types are still pending

Comment 88 Michael OBrien 2009-07-31 14:18:12 EDT

Created attachment 143175 [details]
criteria test suite mods post rev# 4765

Comment 89 Michael OBrien 2009-08-03 23:19:19 EDT

Created attachment 143342 [details]
metamodel impl patch for DI 47,48 and 50 (some collection mapping types are pending

Comment 90 Michael OBrien 2009-08-04 09:20:38 EDT

>see rev# 4777
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4777

266912: Ongoing metamodel API implementation updates
http://bugs.eclipse.org/266912
https://bugs.eclipse.org/bugs/attachment.cgi?id=141476&action=diff
>Design Issues
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_47:_20090715:_Implement_IdentifiableType.getIdType.28.29_for_composite_keys
Part of 50
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_50:_20090727:_Handle_all_mapping_types_in_the_SingularAttribute_constructor
Part of 48
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_48:_20090721:_Implement_Map_support

>Testing: JPA merged with rev 4765/4769 (See MetamodelMetamodelTest.java)
Foundation Core: (known 20 errors unchanged from Friday;s build)
    [junit] Tests run: 8831, Failures: 0, Errors: 20, Time elapsed: 1,218.781 sec
JPA LRG (known 2 failures unchanged from Friday's build
>see
https://bugs.eclipse.org/bugs/attachment.cgi?id=143175&action=diff
    [junit] Tests run: 1300, Failures: 2, Errors: 0, Time elapsed: 697.719 sec

>see also testing change required for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285512

Comment 91 Michael OBrien 2009-08-04 10:45:45 EDT

Created attachment 143400 [details]
MetamodelImpl.type() handler for null type return (handles both Clazz not found and Basic type lookup)

MetamodelImpl.type() handler for null type return (handles both Clazz not found
and Basic type lookup)

>Handle a null (not found) return differently from a Basic Type return (IAE)

>test results
TEST MODEL NAME: (JUnit test): Criteria
Errors: (failures): 0
Fatal Errors: (errors): 0
Passed: 26
Total Tests: 26

TEST MODEL NAME: (JUnit test): MetamodelTestSuite
Errors: (failures): 0
Fatal Errors: (errors): 0
Passed: 3
Total Tests: 3

Comment 92 Michael OBrien 2009-08-06 16:36:35 EDT

Created attachment 143722 [details]
metamodel test model updates for non-default JOINED entity @Inheritance

Comment 93 Michael OBrien 2009-08-06 21:34:06 EDT

>See rev# 4807
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4807

266912: metamodel model update for non-default JOINED @Inheritance for design issues 49 and 50
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_49:_20090723:_OneToMany_on_MappedSuperclass_with_JoinTable_causes_Composite_PK_in_error
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_50:_20090727:_Handle_all_mapping_types_in_the_SingularAttribute_constructor

Test results (JPA LRG): ok on Corei7 with 8gb (7 min)
   [junit] Tests run: 1300, Failures: 0, Errors: 0, Time elapsed: 1,467.537 sec 

Completed: At revision: 4807  

Comment 94 Michael OBrien 2009-08-09 22:43:04 EDT

Created attachment 143862 [details]
Design Issue 58 collection or list attribute type

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_58:_20090807:_ManagedType_Attribute_Initialization_must_differentiate_between_Collection_and_List

>ant test-jpa
    [junit] Tests run: 1300, Failures: 0, Errors: 0, Time elapsed: 419.154 sec

Comment 95 Michael OBrien 2009-08-09 22:51:49 EDT

>see SVN rev# 4820 for DI# 58
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4820

Comment 96 Michael OBrien 2009-08-10 15:49:18 EDT

Created attachment 143957 [details]
Design Issue 58 (add PrivilegedAccessHelper wrapper to ManagedTypeImpl reflective calls)

Comment 97 Michael OBrien 2009-08-10 15:55:05 EDT

>see rev# 4827
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4827

Comment 98 Michael OBrien 2009-08-10 19:05:53 EDT

>See related bug# 236185 on upgrading the compiler level (eclipse and ant) to 1.6 from the present 1.5 for dependent APT bug# 267391

Comment 99 Michael OBrien 2009-08-12 14:04:48 EDT

Created attachment 144276 [details]
Design Issue 49 - Handle PK Field for MappedSuperclass - Option 3b - call hasIdAccessor to check for future IdAccessor and add only if not found in stage 1 - no Iteration - reviewed by Guy

>see
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_49:_20090723:_OneToMany_on_MappedSuperclass_with_JoinTable_causes_Composite_PK_in_error

Comment 100 Michael OBrien 2009-08-12 14:07:46 EDT

Created attachment 144279 [details]
Design Issue 49 - JPA Test patch

>See test model
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#Mapped_Superclass_Test_Model

Comment 101 Michael OBrien 2009-08-12 14:46:55 EDT

>For DI 49 - See rev# 4845
Reviewed by: Guy (with refactor assistance for option 3)
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4845

Comment 102 Michael OBrien 2009-08-13 10:24:40 EDT

Created attachment 144401 [details]
metadata vs metamodel function renaming for development clarity (non-behavioral)

Comment 103 Michael OBrien 2009-08-13 10:25:22 EDT

>see SVN Rev# 4853
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4853

Comment 104 Michael OBrien 2009-08-17 16:31:13 EDT

Created attachment 144734 [details]
DI: 52 refactor: ManagedTypeImpl.hasNoDeclaredAttributeInSuperType refactor

>See SVN rev# 4883
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4883

Comment 105 Michael OBrien 2009-08-19 23:13:39 EDT

Created attachment 145056 [details]
Design Issue 59: PluralAttribute.elementType not set for non-lazy instantiated Collection 

>See DI 59 (type.javaType | elementType is null in this case)
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_59:_20090818:_PluralAttribute.elementType_not_set_for_non-lazy_instantiated_Collection_Attribute

Comment 106 Michael OBrien 2009-08-19 23:34:38 EDT

>See rev# 4916
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4916

Comment 107 Michael OBrien 2009-08-20 16:46:35 EDT

Created attachment 145189 [details]
ManagedType.getDeclaredX() leaks members into entity-entity hierarchy

>see change to treat entity--entity hierarchy the same as mappedSuperclass hierarchies
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_61:_20090820:_ManagedType.getDeclaredX.28.29_leaks_members_into_entity-entity_hierarchy

Comment 108 Michael OBrien 2009-08-20 17:41:39 EDT

>see SVN Rev# 4931
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=4931

Comment 109 Michael OBrien 2009-09-03 10:46:00 EDT

Created attachment 146402 [details]
Prep for DI 63 Map Support

Comment 110 Michael OBrien 2009-09-03 10:47:30 EDT

Created attachment 146403 [details]
Design Issue 67 with 63,66,68 modelling and testing

Comment 111 Michael OBrien 2009-09-04 10:37:31 EDT

Created attachment 146503 [details]
Any EMF interaction in the advanced suite needs to be container-managed friendly

Comment 112 Michael OBrien 2009-09-04 10:42:56 EDT

>see SVN rev# 5054
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5054

Yiping,
    Thanks for catching this - my use of the EMF in this test does not run on a container - I forgot that the advanced model was run on WebLogic etc..  - this is why we get a CCE when we use the not spec cast to the EMF as we are dealing with a proxy of the EMF on WebLogic and not the real EMF.

Comment 113 Michael OBrien 2009-09-11 11:50:07 EDT

Created attachment 146962 [details]
DI 79: MapAttribute keyType requires @MapKey handler in the template case when CMP3Policy.getPKClass() is null 

>Bugzilla backup - switched proxies, this patch is from yesterday's 5104
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5104

Comment 114 Michael OBrien 2009-09-14 11:55:58 EDT

Created attachment 147112 [details]
Use ConversionManager to get the correct EE classLoader if in a container managed context

>See design issue 80 (reviewed by Gordon, Guy and Chris
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_80:_20090914:_MappedSuperclassTypeImpl.create.28.29_does_not_use_ConversionManager_to_get_the_EE_classLoader

Comment 115 Michael OBrien 2009-09-16 11:51:25 EDT

Created attachment 147335 [details]
DI 81: @BasicMap support in ManagedType/MapAttribute

>See Design Issue 81 (note DI 83 fix is in progress)
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_81:_20090914:_Implement_.40BasicMap_DirectMapContainerPolicy_support_in_MapAttributeImpl

>Also see new EE enabled test case the exercises SVN Rev# 5124
http://fisheye2.atlassian.com/changelog/~author=mobrien/eclipselink/?cs=5124
AdvancedJPAJunitTest.testMetamodelMinimalSanityTest()

>failure in Metamodel processing uncovered by new canonical metamodel processing code is fixed

Exception [EclipseLink-7215] (Eclipse Persistence Services - 2.0.0.qualifier): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Could not load the field named [creditCards] on the class [class org.eclipse.persistence.testing.models.jpa.advanced.Buyer_]. Ensure there is a corresponding field with that name defined on the class.
Internal Exception: java.lang.IllegalArgumentException: Can not set static javax.persistence.metamodel.MapAttribute field org.eclipse.persistence.testing.models.jpa.advanced.Buyer_.creditCards to org.eclipse.persistence.internal.jpa.metamodel.CollectionAttributeImpl
	at org.eclipse.persistence.exceptions.ValidationException.invalidFieldForClass(ValidationException.java:2534)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.initializeCanonicalMetamodel(EntityManagerFactoryImpl.java:465)
	at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getMetamodel(EntityManagerFactoryImpl.java:498)
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.getMetamodel(EntityManagerImpl.java:2054)
	at org.eclipse.persistence.testing.tests.jpa.advanced.AdvancedJPAJunitTest.testMetamodelMinimalSanityTest(AdvancedJPAJunitTest.java:193)

>With fix: no JPA LRG issues
    [junit] Tests run: 1308, Failures: 0, Errors: 0, Time elapsed: 1,857.111 sec

Comment 116 Michael OBrien 2009-09-17 13:34:04 EDT

Created attachment 147465 [details]
DI 80: Prepare advanced model metamodel tests for future EE server testing capability via !isJPA10()

>The server tests currently are not JPA 2.0 enabled - this change will run once the JPA 2.0 spec api is detected on the server via !isJPA10()

Comment 117 Michael OBrien 2009-09-18 16:44:56 EDT

Created attachment 147606 [details]
DI 83: @BasicMap elementType (Map value parameter) support in DirectCollectionMapping.attributeClassification - reviewed by Guy

>Design Issue 83 will be checked in when the build restabilizes on monday morning and after the new PFD2 javax.persistence.metamodel API changes are merged.

DI 83: @BasicMap elementType (Map value parameter) support in DirectCollectionMapping.attributeClassification
- we use the typeName from the valueField during metadata processing instead of the type (which may be different when a converter is present on the mapping)
>see bug# 289487

>reviewed by Guy with suggestions by Gordon
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_83:_20090914:_MapAttributeImpl.elementType_incorrectly_set_when_.40ObjectTypeConverter_is_present

Comment 118 Michael OBrien 2009-09-18 16:45:58 EDT

>test-jpa LRG results before SVN update
   [junit] Tests run: 1311, Failures: 0, Errors: 0, Time elapsed: 1,392.633 sec

Comment 119 Michael OBrien 2009-09-18 21:27:52 EDT

>unrelated build issue fixed in 5188
>see SVN Ref# 5189
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5189

https://bugs.eclipse.org/bugs/attachment.cgi?id=147606&action=diff
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_83:_20090914:_MapAttributeImpl.elementType_incorrectly_set_when_.40ObjectTypeConverter_is_present
Reviewed by Guy with architecture discussion by Gordon.
- key change in [DirectCollectionMapping and PluralAttributeImpl] is adding attributeClassification to DirectCollectionMapping so we can get the Map value parameter type using valueField.typeName (see bug# 289487) to cover all use cases including when a converter is on the mapping.

Test Results 
[JPA LRG] off of SVN rev# 5188
    [junit] Tests run: 1311, Failures: 0, Errors: 0, Time elapsed: 1,220.58 sec
[CORE LRG]
After change: Unchanged at 0,14 for JVM specific errors on my build machine - most...
"org.xml.sax.SAXParseException: cvc-enumeration-valid: Value 'FINEST' is not facet-valid"

    [junit] Tests run: 8832, Failures: 0, Errors: 14, Time elapsed: 1,779.119 sec
8832 0 14 99.84% 1779.119 

Before change: same 0,14
8832 0 14 99.84% 1465.515

Comment 120 Michael OBrien 2009-09-25 00:56:49 EDT

Created attachment 148077 [details]
Preliminary (before code-review and cleanup) snapshot of complete IdentifiableTypeImpl for Design Issues 70 to 77

>Preliminary (before code-review and cleanup) snapshot of complete IdentifiableTypeImpl for Design Issues 70 to 77

I started with hasSingleIdAttribute()
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_74:_20090909:_Implement_IdentifiableType.hasSingleIdAttribute.28.29

Comment 121 Michael OBrien 2009-09-25 11:27:45 EDT

Created attachment 148130 [details]
Preliminary (before code-review and cleanup) snapshot of complete IdentifiableTypeImpl for Design Issues 70 to 77 and 56 (null and Object.class IAE relaxation)

>Code (without testing changes)
Preliminary (before code-review and cleanup) snapshot of complete
IdentifiableTypeImpl for Design Issues 70 to 77
And DI 56 (null and Object.class IAE relaxation)

Comment 122 Michael OBrien 2009-09-25 13:54:55 EDT

>See SVN rev# 5303
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5303

266912: Implement remaining 7 IdentifiableTypeImpl functions for Design Issues 70 to 77 and 56 
https://bugs.eclipse.org/bugs/attachment.cgi?id=148130&action=diff 
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_74:_20090909:_Implement_IdentifiableType.hasSingleIdAttribute.28.29 
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_56:_20090807:_IdentifiableTypeImpl.getId_and_getVersion_should_handle_null_and_Object.class_for_non-strict_typing 
Code Reviewed: 
 Guy pending for Core project changes 
Test Results JPA LRG: OK 0,0 
>working view before 5301 
  [junit] Tests run: 1311, Failures: 0, Errors: 0, Time elapsed: 2,115.375 sec 
>After 5301 merge 
   [junit] Tests run: 1320, Failures: 0, Errors: 0, Time elapsed: 1,297.271 sec 

>Core LRG will be run immediately after this commit (so I can share changes with other developers right now) 
>Core LRG clean view at 5301 (14 failures are my known XML parser issue - unrelated) 
  [junit] Tests run: 8834, Failures: 0, Errors: 14, Time elapsed: 3,223.693 sec

Comment 123 Michael OBrien 2009-09-25 14:45:26 EDT

>Review by Guy of the non-metamodel JPA and core parts of the above 70-77 and 56 patch in SVN REv 5303 was just done and is complete
- I need to remove the redundancy in my models for bidirectional relationships - either remove the FK on the table or remove the join table

>Core LRG test results are the same as before changes (a clean view)
    [junit] Tests run: 8834, Failures: 0, Errors: 14, Time elapsed: 2,063.911 sec

Comment 124 Michael OBrien 2009-09-29 14:07:04 EDT

Created attachment 148354 [details]
DI 85: SingularAttributeImpl: Relax IllegalArgumentException checking on autoboxed primitives

266912: DI 85: SingularAttributeImpl: Relax IllegalArgumentException checking on autoboxed primitives
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_85:_20090916:_Relax_IllegalArgumentException_checking_on_autoboxed_primitives

Test Results JPA LRG: OK 0,0  (Oracle 11)
>working view before 5346 (5317)
    [junit] Tests run: 1322, Failures: 0, Errors: 0, Time elapsed: 1,511.126 sec
>After 5346 merge 
    [junit] Tests run: 1322, Failures: 0, Errors: 0, Time elapsed: 1,270.925 sec

Comment 125 Michael OBrien 2009-10-01 13:53:47 EDT

>Before closing this enhancement bug# 266912, a review of the outstanding design issues in in progress to minimize any possible runtime issues before the final build next week.
From
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#Design_Issues

> Implement or deprecate
DI 78: 20090909: Composite @IdClass on inherited MappedSuperclass chain causes new ValidationException
DI 86: 20090921: Handle Embeddable Type keyType in MapAttributeImpl constructor
DI 82: 20090914: Verify all is*Policy() calls for MapAttributeImpl instances
DI 65: 20090827: Handle DirectCollection elementType retrieval in the absence of a generic type
DI 69: 20090831: Object.class as a default javaType is not compatible with JPA 1.0
DI 60: 20090820: Refactor SingularAttribute and PluralAttribute constructor elementType discovery up into Attribute
DI 55: 20090806: Basic Type processing currently lazy loaded
DI 53: 20090729: Verify that inheritied non-JPA class mappings are handled by the Metamodel

> May be fixed - verify
DI 67:20090827: AggregateCollectionMapping support in PluralAttribute
DI 62: 20090820: Add support for Embeddable Collections as part of AGGREGATE_COLLECTION support
DI 61: 20090820: ManagedType.getDeclaredX() leaks members into entity-entity hierarchy
DI 51: 20090728: Implement ManagedTypeImpl.getDeclaredAttributes() for non-collections 
DI 50: 20090727: Handle all mapping types in the SingularAttribute constructor 

> Recently already fixed
DI 84: 200909015: MapAttribute missing support for UC8: @MapKey with default name attribute
DI 80: 20090914: MappedSuperclassTypeImpl.create() does not use ConversionManager to get the EE classLoader
DI 64: 20090825: ManagedTypeImpl.isAttributeDeclaredOnlyInLeafType() fails to find attributes declared root of mappedSuperclass<--entity<--entity hierarcy

Comment 126 Michael OBrien 2009-10-02 07:47:08 EDT

Created attachment 148633 [details]
20091001 specification update changed Metamodel.type to .managedType - no behavioral change

Comment 127 Michael OBrien 2009-10-02 11:41:15 EDT

Created attachment 148658 [details]
20091001 specification update changed Metamodel.type to .managedType - no behavioral change

>an ant build before testing showed that I missed refactoring the [modelgen] project because it was not imported into my Eclipse view

Comment 128 Michael OBrien 2009-10-02 12:10:43 EDT

> see SVN rev# 5425
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5425
>merged with 5391 
Test Results JPA LRG: OK 0,0  (Oracle 11) based only on SVN rev# 5413 or 5419 but not 5414 
   [junit] Tests run: 1324, Failures: 0, Errors: 0, Time elapsed: 1,763.718 sec

Comment 129 Michael OBrien 2009-10-07 12:58:46 EDT

>JPA 2.0 specification preview jar in SVN is in sync as of 5476 with 5425
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5476

Comment 130 Michael OBrien 2009-10-08 16:55:57 EDT

Created attachment 149174 [details]
DI 89 and 91: Make the Metamodel serializable and throw an IAE for IdentifiableType.getDeclaredId when required

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_89:_20091007:_Metamodel_Implementation_must_implement_Serializable_-_required_by_Criteria_API
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_91:_20091008:_ManagedType.getDeclaredAttribute.28.29_does_not_throw_expected_IAE_for_Entity.28target.29-MappedSuperclass-MappedSuperclass.28attribute.29_Hierarchy

Comment 131 Michael OBrien 2009-10-08 17:16:36 EDT

>see SVN rev# 5506
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5506

Comment 132 Michael OBrien 2009-10-13 15:51:27 EDT

Created attachment 149472 [details]
reduce verbosity of ManagedType.toString() for descriptors

>New signature of ManagedTypes

EmbeddableTypeImpl@4118808:Observation [ javaType: class org.eclipse.persistence.testing.models.jpa.metamodel.Observation descriptor: RelationalDescriptor(org.eclipse.persistence.testing.models.jpa.metamodel.Observation --> []), mappings: 0]

EntityTypeImpl@4119781:Enclosure [ javaType: class org.eclipse.persistence.testing.models.jpa.metamodel.Enclosure descriptor: RelationalDescriptor(org.eclipse.persistence.testing.models.jpa.metamodel.Enclosure --> [DatabaseTable(CMP3_MM_ENCLOSURE)]), mappings: 4]

MappedSuperclassTypeImpl@4121856:Corporation [ javaType: class org.eclipse.persistence.testing.models.jpa.metamodel.Corporation descriptor: RelationalDescriptor(org.eclipse.persistence.testing.models.jpa.metamodel.Corporation --> [DatabaseTable(__METAMODEL_RESERVED_IN_MEM_ONLY_TABLE_NAME)]), mappings: 1]

Comment 133 Michael OBrien 2009-10-13 15:59:15 EDT

>See SVN rev# 5533
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5533

Comment 134 Michael OBrien 2009-10-14 10:34:24 EDT

Created attachment 149534 [details]
DI 92: Move metamodel field from EntityManagerFactoryImpl to EntityManagerSetupImpl for GC performance

Comment 135 Michael OBrien 2009-10-15 16:26:23 EDT

Created attachment 149681 [details]
DI 54: throw IAE on any Metamodel.managedType(clazz) call where clazz is wrapped by a BasicType - used to return null - use MetamodelImpl.getType(clazz) instead 

>See bug# 285512 and SVN rev# 5540
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5540
- reviewed by Gordon

Comment 136 Michael OBrien 2009-10-15 16:29:26 EDT

Created attachment 149683 [details]
DI 94: Split up test framework into granular test cases (part 1 of 2)

>This is part of the work surrounding the change from using .isDerivedId() to using the new .isJPAId() in the larger metadata processing by Guy
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_94:_20091015:_Split_and_Granularize_Test_Suite
- discussed with Guy

Comment 137 Michael OBrien 2009-10-19 20:51:23 EDT

Created attachment 149933 [details]
DI 95 and 96 ttribute.getJavaMember() and .getPersistentAttributeType() modifications for MappedSuperclasses and ManyToOne mappings - with DI 94 - test case splitting part 2 of 3

>Without changes (corei7-920 12Gb - remote 100Mb/s Oracle 11)
    [junit] Tests run: 1449, Failures: 0, Errors: 0, Time elapsed: 1,699.798 sec
>With changes 1
    [junit] Tests run: 1497, Failures: 0, Errors: 0, Time elapsed: 2,029.487 sec
>With changes 2
    [junit] Tests run: 1497, Failures: 0, Errors: 0, Time elapsed: 1,983.264 sec

17-19% increase in run time because each test case requires em creation to be independent execution standards.

Comment 138 Michael OBrien 2009-10-21 16:45:31 EDT

Created attachment 150163 [details]
DI 94: increase test suite performance from 6 min to 2 sec by caching EntityManagerFactory


Previously
    [junit] Tests run: 1510, Failures: 0, Errors: 0, Time elapsed: 2,009.116 sec
Current
    [junit] Tests run: 1523, Failures: 0, Errors: 0, Time elapsed: 1,432.699 sec
>result is that test time has been reduced by 40%
>we are down to 2 sec from a max of 6 min

[EL Finer]: 2009-10-21 16:44:00.306--DatabaseSessionImpl(995829153)--Thread(Thread[Thread-3,6,main])--Begin Metamodel
[EL Finer]: 2009-10-21 16:44:01.462--DatabaseSessionImpl(995829153)--Thread(Thread[Thread-3,6,main])--Finished Metamodel
TEST MODEL NAME: (JUnit test): Metamodel
Errors: (failures): 0
Fatal Errors: (errors): 0
Passed: 97
Total Tests: 97


[EL Finer]: 2009-10-21 16:44:28.372--DatabaseSessionImpl(995829153)--Thread(Thread[Thread-4,6,main])--Begin Criteria
[EL Finer]: 2009-10-21 16:45:24.023--DatabaseSessionImpl(995829153)--Thread(Thread[Thread-4,6,main])--Finished Criteria
TEST MODEL NAME: (JUnit test): Criteria
Errors: (failures): 0
Fatal Errors: (errors): 0
Passed: 126
Total Tests: 126

Comment 139 Michael OBrien 2009-10-29 14:39:31 EDT

Created attachment 150861 [details]
DI 96: Attribute.getPersistentAttributeType requires accessor map on core Project for ManyToOne identification and OneToMany on MappedSuperclass

Comment 140 Michael OBrien 2009-10-29 23:26:21 EDT

Created attachment 150893 [details]
DI 96: Attribute.getPersistentAttributeType requires accessor map on core Project for ManyToOne identification and OneToMany on MappedSuperclass

Comment 141 Michael OBrien 2009-11-03 23:11:17 EST

Created attachment 151264 [details]
DI 96: Use flag on ManyToManyMapping to signify a OneToMany unidirectional and a flag on OneToOneMapping to signify an ManyToOne

Comment 142 Michael OBrien 2009-11-05 15:58:08 EST

Created attachment 151497 [details]
DI 86: preliminary_mapkey_support_for_idclass_with_only_generics_set_testcases_pending

>Doing regression testing and extending test model surrounding existing Enclosure.class
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_86:_20090921:_Handle_Embeddable_Type_keyType_in_MapAttributeImpl_constructor

Comment 143 Michael OBrien 2009-11-06 09:33:45 EST

>The metamodel part of the fix for bug# 294254 is in the patch for DI 86

Comment 144 Michael OBrien 2009-11-08 23:59:54 EST

Created attachment 151667 [details]
DI 86: MapAttribute  support for entity mapkey

>Test model changes
@Entity(name="ManufacturerMetamodel")
public class Manufacturer extends Corporation implements java.io.Serializable{
...
    // UC9: no targetEntity, no MapKey, but generics are set (MapKey has an IdClass with an Embeddable)
    @OneToMany(cascade=CascadeType.ALL, mappedBy="mappedManufacturerUC9")
---> new    private Map<Board, Enclosure> enclosureByBoardMapUC9;
}
 
@Entity(name="EnclosureMetamodel")
@IdClass(org.eclipse.persistence.testing.models.jpa.metamodel.EnclosureIdClassPK.class)
public class Enclosure implements java.io.Serializable {
...    
    @Id    @Column(name="TYPE")
    public String type;
    @Id    @Column(name="LENGTH")
    protected String length;
    @Id    @Column(name="WIDTH")
    private String width;
 
    // The M:1 side is the owning side
    @Id    @ManyToOne
    @JoinColumn(name="PERSON_ID")
---> new    private Manufacturer mappedManufacturerUC9;
}
 
public class EnclosureIdClassPK {
...
    public String type;
    protected String length;
    private String width;
---> new    private Integer mappedManufacturerUC9;
}

>Testing before change
The following test passes with the change submitted in the DI86 patch below (without this fix we get the following test failure with the new model change above) 

TEST SUITE NAME: org.eclipse.persistence.testing.tests.jpa.metamodel.MetamodelMetamodelTest
TEST NAME: testMapAttribute_getKeyJavaType_UC9_DI86_Embeddable_IdClass_keyType_Method(org.eclipse.persistence.testing.tests.jpa.metamodel.MetamodelMetamodelTest)
##FAILURE##
RESULT:      Error (failure)
junit.framework.AssertionFailedError: expected:<class org.eclipse.persistence.testing.models.jpa.metamodel.Board> but was:<class java.lang.Integer>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:277)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:71)
	at org.eclipse.persistence.testing.tests.jpa.metamodel.MetamodelMetamodelTest.testMapAttribute_getKeyJavaType_UC9_DI86_Embeddable_IdClass_keyType_Method(MetamodelMetamodelTest.java:4502)

>JPA LRG: 0,0

Comment 145 Michael OBrien 2009-11-09 14:11:07 EST

>see SVN rev# 5761 for DI 86
http://fisheye2.atlassian.com/changelog/eclipselink/?cs=5761

Comment 146 Michael OBrien 2009-11-09 14:13:09 EST

>See new DI 98 discussion on handling differences between MapContainerPolicy and MappedKeyMapContainerPolicy delivery of the Map keyType field to MapAttribute.

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_98:_20091109:_MapAttribute_keyType_processing_should_offload_more_to_MappedKeyContainerPolicy.keyMapping

         * We have the following policy structure and behavior
         * MapContainerPolicy (use keyField or PK class)
         *   --> MappedKeyMapContainerPolicy (use keyMapping.mapKeyTargetType or attributeClassification) 
         *   
         *   Use Case segmentation for keyType 
                A) MapContainerPolicy 
                    A1) keyField set (lazy loaded) 
                        UC2 
                            @OneToMany(cascade=ALL, mappedBy="mappedEmployerUC2") 
                            @MapKey(name="name") 
                            private Map<String, HardwareDesigner> hardwareDesignersMapUC2; 
                        UC4 
                            @OneToMany(targetEntity=HardwareDesigner.class, cascade=ALL, mappedBy="mappedEmployerUC4") 
                            @MapKey(name="name") 
                            private Map hardwareDesignersMapUC4; 
                        UC8 
                            @OneToMany(cascade=ALL, mappedBy="mappedEmployerUC8") 
                            @MapKey // name attribute will default to "id" 
                            private Map<Integer, HardwareDesigner> hardwareDesignersMapUC8; 
                    A2) Use mapPolicy.elementDescriptor.cmppolicy.pkClass (since KeyField == null) 
                        Computer.enclosures 
                            @OneToMany(mappedBy="computer", cascade=ALL, fetch=EAGER) 
                            @MapKey // key defaults to an instance of the composite pk class 
                            private Map<EnclosureIdClassPK, Enclosure> enclosures; 
                        or (get keyClass from mapping if the Id is a get() function) 
                            TBD - use reflection 
                B) MappedKeyMapContainerPolicy 
                    B1) mapKeyTargetType set on the keyMapping 
                        UC9 
                            @OneToMany(cascade=CascadeType.ALL, mappedBy="mappedManufacturerUC9") 
                            private Map<Board, Enclosure> enclosureByBoardMapUC9; 
                    B2) Use AttributeClassification (since keyMapping.attributeAccessor.attributeClass == null) 
                        UC1a - used to return the Integer PK 
                            @OneToMany(cascade=ALL, mappedBy="mappedEmployerUC1a") 
                            private Map<String, HardwareDesigner> hardwareDesignersMapUC1a; 
                        UC7 - used to return the Integer PK 
                            @OneToMany(targetEntity=HardwareDesigner.class, cascade=ALL, mappedBy="mappedEmployerUC7") 
                            private Map<String, HardwareDesigner> hardwareDesignersMapUC7;

Comment 147 Michael OBrien 2009-11-09 14:17:05 EST

Created attachment 151724 [details]
DI 98: Discussion patch - use_more_MappedKeyMapContainerPolicy_but_keep_MapContainerPolicy_custom_handlers

Comment 148 Michael OBrien 2009-11-10 16:10:28 EST

>For both of the related DI 98 issues in bug# 294765 and bug# 294811 - part of the context is the fact that the keyMapping only exists on the MappedKeyMapContainerPolicy and not on the other two MapContainerPolicy and DirectMapContainerPolicy because of a constraint on the map key type.
 ContainerPolicy (A)
    +=== InterfaceContainerPolicy (A)
             +=== DirectMapContainerPolicy
             +=== MapContainerPolicy (use keyField or PK class)
                      +=== MappedKeyMapContainerPolicy (use keyMapping.mapKeyTargetType or attributeClassification)

Comment 149 Michael OBrien 2009-11-10 16:25:37 EST

Created attachment 151885 [details]
DI 98: leverage MappedKeyMapContainerPolicy, add basicMap Support, keep 294811 and 294768 woirkarounds for keyType when MapKey not specified

Comment 150 Michael OBrien 2009-11-23 00:35:46 EST

>API complete - all priority issues resolved including the last 288972
Any remaining minor issues are documented on the design wiki and may be scheduled in the future
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api

A final transaction to remove non-functional deprecated/commented code from the test model will be done before release.

Comment 151 Michael OBrien 2011-01-13 11:31:44 EST

>changes in bug# 333656 (if it is an issue) may affect design issues 98, 79 and 86 - review them after
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_98:_20091109:_MapAttribute_keyType_processing_should_offload_more_to_MappedKeyContainerPolicy.keyMapping
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_79:_20090910:_MapAttribute_keyType_requires_.40MapKey_handler_in_the_template_case_when_CMP3Policy.getPKClass.28.29_is_null
http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_86:_20090921:_Handle_Embeddable_Type_keyType_in_MapAttributeImpl_constructor

Comment 152 Michael OBrien 2011-03-03 13:17:37 EST

>The workaround for DI 101 and bug# 338837 fix the IAE issue for Criteria/Metamodel users attempting to use an EntityType that is not found

Exception in thread "main" java.lang.IllegalArgumentException: The type [null] is not the expected [EntityType] for the key class [class org.eclipse.persistence.example.distributed.collatz.model.UnitOfWork].

http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/metamodel_api#DI_101:_20100218:_Descriptor.javaClass_is_null_on_a_container_EM_for_a_specific_case

>workaround is
<exclude-unlisted-classes>false</exclude-unlisted-classes>
or
<class>org.eclipse.persistence.example.distributed.collatz.model.UnitOfWork</class>

Comment 153 Eclipse Webmaster 2022-06-09 10:26:52 EDT

The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink