Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-1629

PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies

    Details

    • Sprint:
      2017 Week 26-27, 2017 Week 28-29
    • Steps to Reproduce:
      Hide

      Define two marshalling strategies mapping different persistence units.
      This problem only happens while using the same implementation class of a ObjectMarshallingStrategy but initialized with different parameters.

      Show
      Define two marshalling strategies mapping different persistence units. This problem only happens while using the same implementation class of a ObjectMarshallingStrategy but initialized with different parameters.
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.

      When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.

      The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.

      This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
      Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.

      In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  mfusco Mario Fusco
                  Reporter:
                  ngs_mtech Manuel Castro
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - 3 days
                    3d
                    Remaining:
                    Remaining Estimate - 3 days
                    3d
                    Logged:
                    Time Spent - Not Specified
                    Not Specified