Spring Roo
  1. Spring Roo
  2. ROO-733

Roo generated data on demand types are not aware of fields annotated with JSR 303 @Size

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 1.1.0.M2
    • Component/s: TESTING
    • Labels:
      None

      Description

      Roo generated data on demand types are not aware of fields annotated with JSR 303 @Size.

        Issue Links

          Activity

          Hide
          Stefan Schmidt added a comment -

          Changing the issue type of this ticket given this is not really a bug but rather a 'feature improvement'. This limitation is already noted in the known issues section of the reference guide. Further details about the complexity of supporting the full specification of the JSR-303 spec are offered in ROO-804.

          Please vote for this ticket so we can gauge community interest.

          Show
          Stefan Schmidt added a comment - Changing the issue type of this ticket given this is not really a bug but rather a 'feature improvement'. This limitation is already noted in the known issues section of the reference guide. Further details about the complexity of supporting the full specification of the JSR-303 spec are offered in ROO-804 . Please vote for this ticket so we can gauge community interest.
          Hide
          Stefan Schmidt added a comment -

          Assigning to Alan given he has implemented this improvement. The known issues section still needs clean up.

          Show
          Stefan Schmidt added a comment - Assigning to Alan given he has implemented this improvement. The known issues section still needs clean up.
          Hide
          Alan Stewart added a comment -

          Checks for @Size, @Max, @Min, and @Column(length = ?) Added

          Show
          Alan Stewart added a comment - Checks for @Size, @Max, @Min, and @Column(length = ?) Added
          Hide
          Gordon Dickens added a comment -

          Is this resolved in 1.1.0M2? I am getting constraint violation exceptions with tests generated by --testAutomatically for the following entities:

          entity --class ~.domain.security.Users --testAutomatically --table security_users
          field string --fieldName username --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
          field string --fieldName password --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
          field string --fieldName passwordAgain --transient --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users
          field string --fieldName salt --notNull --sizeMax 25 --class ~.domain.security.Users
          field boolean --fieldName enabled --class ~.domain.security.Users
          controller scaffold --class ~.web.security.UsersController --entity ~.domain.security.Users

          entity --class ~.domain.security.Authorities --testAutomatically --table security_roles
          field string authority --notNull --sizeMax 50 --sizeMin 8 --regexp ^ROLE_[A-Z]* --class ~.domain.security.Authorities
          controller scaffold --class ~.web.security.AuthoritiesController --entity ~.domain.security.Authorities

          entity --class ~.domain.security.UserAuthority --testAutomatically --table security_role_user
          field reference --fieldName users --type ~.domain.security.Users --class ~.domain.security.UserAuthority
          field reference --fieldName authorities --type ~.domain.security.Authorities --class ~.domain.security.UserAuthority
          controller scaffold --class ~.web.security.UserAuthorityController --entity ~.domain.security.UserAuthority

          Show
          Gordon Dickens added a comment - Is this resolved in 1.1.0M2? I am getting constraint violation exceptions with tests generated by --testAutomatically for the following entities: entity --class ~.domain.security.Users --testAutomatically --table security_users field string --fieldName username --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users field string --fieldName password --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users field string --fieldName passwordAgain --transient --notNull --sizeMax 50 --sizeMin 3 --class ~.domain.security.Users field string --fieldName salt --notNull --sizeMax 25 --class ~.domain.security.Users field boolean --fieldName enabled --class ~.domain.security.Users controller scaffold --class ~.web.security.UsersController --entity ~.domain.security.Users entity --class ~.domain.security.Authorities --testAutomatically --table security_roles field string authority --notNull --sizeMax 50 --sizeMin 8 --regexp ^ROLE_ [A-Z] * --class ~.domain.security.Authorities controller scaffold --class ~.web.security.AuthoritiesController --entity ~.domain.security.Authorities entity --class ~.domain.security.UserAuthority --testAutomatically --table security_role_user field reference --fieldName users --type ~.domain.security.Users --class ~.domain.security.UserAuthority field reference --fieldName authorities --type ~.domain.security.Authorities --class ~.domain.security.UserAuthority controller scaffold --class ~.web.security.UserAuthorityController --entity ~.domain.security.UserAuthority
          Hide
          Alan Stewart added a comment - - edited

          The users tests fail because you have annotated a transient field with a @NotNull - remove this and it will pass, and we don't support the @Pattern annotation used in Authorities. The test data generated in DoD is not compatible with the pattern specified, hence the failure.

          Show
          Alan Stewart added a comment - - edited The users tests fail because you have annotated a transient field with a @NotNull - remove this and it will pass, and we don't support the @Pattern annotation used in Authorities. The test data generated in DoD is not compatible with the pattern specified, hence the failure.
          Hide
          Milan Agatonovic added a comment -

          Hi, I think I have a same problem.
          I generate my domain class IpRange like this:
          entity --class ~.domain.IpRange --testAutomatically
          field string --notNull --fieldName startIp --regexp ^(([0-9]|[1-9][0-9]|1[0-9]

          {2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}

          |2[0-4][0-9]|25[0-5])$
          field string --notNull --fieldName endIp --regexp ^(([0-9]|[1-9][0-9]|1[0-9]

          {2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}

          |2[0-4][0-9]|25[0-5])$

          tests fail because of:
          <error message="validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ]" type="javax.validation.ConstraintViolationException">javax.validation.ConstraintViolationException: validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ]

          Is there any other way (either now or planned for future) where I can supply valid data, without a need to push in aj file and change IpRangeDataOnDemand.java?

          Show
          Milan Agatonovic added a comment - Hi, I think I have a same problem. I generate my domain class IpRange like this: entity --class ~.domain.IpRange --testAutomatically field string --notNull --fieldName startIp --regexp ^(( [0-9] | [1-9] [0-9] |1 [0-9] {2}|2 [0-4] [0-9] |25 [0-5] )\.){3}( [0-9] | [1-9] [0-9] |1 [0-9] {2} |2 [0-4] [0-9] |25 [0-5] )$ field string --notNull --fieldName endIp --regexp ^(( [0-9] | [1-9] [0-9] |1 [0-9] {2}|2 [0-4] [0-9] |25 [0-5] )\.){3}( [0-9] | [1-9] [0-9] |1 [0-9] {2} |2 [0-4] [0-9] |25 [0-5] )$ tests fail because of: <error message="validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ] " type="javax.validation.ConstraintViolationException">javax.validation.ConstraintViolationException: validation failed for classes [com.fizzback.ipvalidator.domain.IpRange] during persist time for groups [javax.validation.groups.Default, ] Is there any other way (either now or planned for future) where I can supply valid data, without a need to push in aj file and change IpRangeDataOnDemand.java?
          Hide
          Alan Stewart added a comment -

          Since this Jira issue is related to @Size, would you please raise a new feature request for @Pattern support in data on demand. We like to keep the Jira tickets as fine grained as possible.

          As a workaround now, you can always push-in refactor the Dod ITD and modify the methods yourself to supply @Pattern-compatible test data.

          Show
          Alan Stewart added a comment - Since this Jira issue is related to @Size, would you please raise a new feature request for @Pattern support in data on demand. We like to keep the Jira tickets as fine grained as possible. As a workaround now, you can always push-in refactor the Dod ITD and modify the methods yourself to supply @Pattern-compatible test data.
          Hide
          brian walsh added a comment -

          Hi. I'm enjoying my experimentation with Roo.

          However, I ran into this problem within the first 30 minutes.

          A newbie question: can you define "you can always push-in refactor the Dod ITD and modify the methods yourself"

          Show
          brian walsh added a comment - Hi. I'm enjoying my experimentation with Roo. However, I ran into this problem within the first 30 minutes. A newbie question: can you define "you can always push-in refactor the Dod ITD and modify the methods yourself"

            People

            • Assignee:
              Alan Stewart
              Reporter:
              Stefan Schmidt
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: