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

PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.1.0.Final
    • 6.4.0.Final, 6.5.0.Final, 7.0.0.Final
    • core engine, kie server
    • None
    • 2017 Week 26-27, 2017 Week 28-29
    • 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.
    • NEW
    • 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.

      Attachments

        Issue Links

          Activity

            People

              mfusco@redhat.com Mario Fusco
              ngs_mtech_jira Manuel Castro (Inactive)
              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