Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-13168

Maintenance Document Serializer dumping EclipseLink internals to XML

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.5
    • Fix Version/s: 2.6
    • Component/s: Development, JPA
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      The maintenance framework is dumping far too much information into the XML, it containing the EL internals which store the database mapping items and the indirection classes used to hold lists.

        Attachments

          Issue Links

            Activity

            Hide
            gathreya Gayathri Athreya added a comment - - edited

            This is happening in trans docs too. I am seeing lots of eclipselink information being dumped into the XML like the following

             <budgetDocumentVersions class="org.eclipse.persistence.indirection.IndirectList" serialization="custom">
                  <unserializable-parents/>
                  <vector>
                    <default>
                      <capacityIncrement>0</capacityIncrement>
                      <elementCount>0</elementCount>
                      <elementData/>
                    </default>
                  </vector>
                  <org.eclipse.persistence.indirection.IndirectList>
                    <default>
                      <initialCapacity>10</initialCapacity>
                      <isListOrderBrokenInDb>false</isListOrderBrokenInDb>
                      <isRegistered>true</isRegistered>
                      <useLazyInstantiation>true</useLazyInstantiation>
                      <valueHolder class="org.eclipse.persistence.internal.indirection.UnitOfWorkQueryValueHolder"/>
                    </default>
                  </org.eclipse.persistence.indirection.IndirectList>
                </budgetDocumentVersions>
            
            Show
            gathreya Gayathri Athreya added a comment - - edited This is happening in trans docs too. I am seeing lots of eclipselink information being dumped into the XML like the following <budgetDocumentVersions class= "org.eclipse.persistence.indirection.IndirectList" serialization= "custom" > <unserializable-parents/> <vector> < default > <capacityIncrement>0</capacityIncrement> <elementCount>0</elementCount> <elementData/> </ default > </vector> <org.eclipse.persistence.indirection.IndirectList> < default > <initialCapacity>10</initialCapacity> <isListOrderBrokenInDb> false </isListOrderBrokenInDb> <isRegistered> true </isRegistered> <useLazyInstantiation> true </useLazyInstantiation> <valueHolder class= "org.eclipse.persistence.internal.indirection.UnitOfWorkQueryValueHolder" /> </ default > </org.eclipse.persistence.indirection.IndirectList> </budgetDocumentVersions>
            Hide
            jkeller Jonathan Keller added a comment -

            Not surprised - it's mostly the same code. It won't affect KFS transactional documents since it does not populate any document data into the XML document content stored in KEW.

            There used to be logic (for OJB) which handled these implemention-specific lists and container classes. I don't know if we need them or not. For transactional documents, it's different. That XML is used (I thought) only for searchable attributes. But, for the maintenance documents, the objects are reconstituted from that XML and possibly later persisted back to the database.

            I'm not sure what the right thing to go here is. With OJB, our object were "normal", just wrapped in proxies. But, with JPA, the classes themselves have been modified to contain these extra attributes. I don't know the ramifications of eliminating those EL elements during the serialization process.

            Show
            jkeller Jonathan Keller added a comment - Not surprised - it's mostly the same code. It won't affect KFS transactional documents since it does not populate any document data into the XML document content stored in KEW. There used to be logic (for OJB) which handled these implemention-specific lists and container classes. I don't know if we need them or not. For transactional documents, it's different. That XML is used (I thought) only for searchable attributes. But, for the maintenance documents, the objects are reconstituted from that XML and possibly later persisted back to the database. I'm not sure what the right thing to go here is. With OJB, our object were "normal", just wrapped in proxies. But, with JPA, the classes themselves have been modified to contain these extra attributes. I don't know the ramifications of eliminating those EL elements during the serialization process.
            Hide
            jkeller Jonathan Keller added a comment -

            And, this is more-or-less a rediscovery. You can see the notes I had on this a year ago here: KULRICE-9105

            Show
            jkeller Jonathan Keller added a comment - And, this is more-or-less a rediscovery. You can see the notes I had on this a year ago here: KULRICE-9105

              People

              • Assignee:
                Unassigned
                Reporter:
                jkeller Jonathan Keller
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: