Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-13168

Maintenance Document Serializer dumping EclipseLink internals to XML

    Details

    • Type: Task Task
    • Status: Open Open
    • Priority: Major 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:
    • Similar issues:
      KULRICE-9715Update XStream-based XML serializers to skip JPA generated fields
      KULRICE-9187Maintenance framework needs a hook that gets executed prior to serialization to XML
      KULRICE-9105Determine how to do a more efficient and less wasteful approach for XML object serialization for the maintenenace framework
      KULRICE-8180Need a way to control what properties are serialized in maintenance documents.
      KULRICE-12304Maintenance document "just-in-time" converter
      KULRICE-12033Add annotation to enable serialization opt-in / opt-out for individual maintenance doc fields
      KULRICE-9665Implement targeted encryption within maintenance document XML
      KULRICE-14257Invalid Unicode control characters cause failures in serializing document fields for SOAP requests
      KULRICE-6895Xstream unmarshalling of BO Note (in maintenance documents) leads to a stacktrace
      KULRICE-11812KRAD maintenance docs break if there are lazy relationships in JPA due to copying by serialization
    • 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.

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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:
              Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Structure Helper Panel