OpenJPA
  1. OpenJPA
  2. OPENJPA-1105 OpenJPA 2.0 iteration 8 primary task
  3. OPENJPA-1111

Validation mode of callback should cause a PersistenceException when no provider is available

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M2
    • Fix Version/s: 2.0.0-M3
    • Component/s: validation
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      Validation mode of callback should cause a PersistenceException when no provider is available.
      This is a continuation of OPENJPA-1102 and OPENJPA-1068.

      1. OPENJPA-1111-part2.patch
        6 kB
        Donald Woods
      2. OPENJPA-1111.patch
        36 kB
        Donald Woods
      3. OPENJPA-1111.patch
        38 kB
        Donald Woods

        Issue Links

          Activity

          Hide
          Donald Woods added a comment -

          Part 2 - updated WrapperedException to properly pass on the exception, updated ValidationException to allow for setting the fatal flag, and updated the location of the localizer messages for ValidationUtils.

          Show
          Donald Woods added a comment - Part 2 - updated WrapperedException to properly pass on the exception, updated ValidationException to allow for setting the fatal flag, and updated the location of the localizer messages for ValidationUtils.
          Hide
          Donald Woods added a comment -

          Updated patch that uses geronimo-validation_1.0_spec instead of the RI API for the validation itests

          Show
          Donald Woods added a comment - Updated patch that uses geronimo-validation_1.0_spec instead of the RI API for the validation itests
          Hide
          Donald Woods added a comment -

          Patch file for easy review. Incorporates the plugin concept from Pinaki's patch attached to OPENJPA-1114.

          Show
          Donald Woods added a comment - Patch file for easy review. Incorporates the plugin concept from Pinaki's patch attached to OPENJPA-1114 .
          Hide
          Pinaki Poddar added a comment -

          > but I think we still have the issue of when to set the alias to "jpa2", since we need all of the product derivations applied to the config before we try to initialize the plugin.

          Bootstapping (i.e. setting configuration plugin values via each discovered ProductDerivation) and instantiation/initialization of these plugins are not only two separate concepts, they occur in sequential phase. So I am missing the issue you raised.
          ProductDerivation are applied in deterministic order – so that we know who can overwrite whose settings. I have not read through this Validation feature, but from a layman's point of view PersistenceProductDerivation seems to be the right place for setting the plugins value to "jpa2" (btw, that "jpa2" is poor naming – please change it). Its value i.e. ValidatingLifeCycleEventManager will really get instantiated much later.

          Another idea (I think the implementation of VLEM is almost there) is as VLEM anyway extends previous LEM, if you can not initialize a VLEM because ValidationFactory/validation provider is missing, validation mode is set to NONE (or whatever) you can degenerate VLEM instance's behavior to that of LEM. In that case you do not even need to configure it – so it will be hardcoded to VLEM (as opposed to LEM).

          Show
          Pinaki Poddar added a comment - > but I think we still have the issue of when to set the alias to "jpa2", since we need all of the product derivations applied to the config before we try to initialize the plugin. Bootstapping (i.e. setting configuration plugin values via each discovered ProductDerivation) and instantiation/initialization of these plugins are not only two separate concepts, they occur in sequential phase. So I am missing the issue you raised. ProductDerivation are applied in deterministic order – so that we know who can overwrite whose settings. I have not read through this Validation feature, but from a layman's point of view PersistenceProductDerivation seems to be the right place for setting the plugins value to "jpa2" (btw, that "jpa2" is poor naming – please change it). Its value i.e. ValidatingLifeCycleEventManager will really get instantiated much later. Another idea (I think the implementation of VLEM is almost there) is as VLEM anyway extends previous LEM, if you can not initialize a VLEM because ValidationFactory/validation provider is missing, validation mode is set to NONE (or whatever) you can degenerate VLEM instance's behavior to that of LEM. In that case you do not even need to configure it – so it will be hardcoded to VLEM (as opposed to LEM).

            People

            • Assignee:
              Donald Woods
              Reporter:
              Donald Woods
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development