Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.1
    • Fix Version/s: Backlog
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-4612KIM DTOs should be using java.util.Date
      KULRICE-1681Create KOM DTOs in the kom-api module and move BOs to the kom module
      KULRICE-4505Decide on and document guidelines for how service contracts, DTOs, and implementations should be versioned
      KULRICE-3602Handle null values consistently in KIM entity DTOs
      KULRICE-5152Add version number to KRMS DTOs
      KULRICE-3517SOAPServiceDefinition should check that the serviceInterface is an actual interface if it is set
      KULRICE-1673Make KIM DTOs serializable
      KULRICE-4898Remove org.kuali.rice.kew.web.session.Authentication and calls to it. Replace with KIM permissions.
      KULRICE-2319Separate API calls that can update KIM data into separate interfaces
      KULRICE-5095Make sure converted BO/DTOs are using more generic names for fields (i.e. stop using the class in the field names)
    • Rice Module:
      KIM

      Description

      Leo found an odd issue in KIM yesterday. AZ's implementation of KIM uses an LDAP backend - but then there's some test users who don't exist in the LDAP, so to create those, Arizona was adding the users as injected Spring beans. However, in Rice 1.0.1 that didn't work - it wouldn't let Leo inject a KimEntityNameInfo into a KimEntityInfo bean.

      This is because KimEntityInfo implements KimEntity. KimEntity#getDefaultName returns KimEntityName. KimEntityInfo#getDefaultName returns KimEntityNameInfo, and rather more to the point, KimEntityInfo#setDefaultName takes in a KimEntityNameInfo object. When Spring introspects KimEntityInfo for properties, then, it does not consider "defaultName" as a property as its getter returns one type (KimEntityName, as the interface wins) and the setter takes in a different type (KimEntityNameInfo; a sub-type sure, but different). So Leo created a KimEntity implementation which returned and took in interfaces; that worked.

      Of course, this wouldn't happen if KimEntityInfo's getDefultName returned the interface - KimEntityName - and its setter took in KimEntityName, which is what I'm proposing here. DefaultName isn't the only property this issue applies to...

        Activity

        Hide
        James Smith added a comment -

        Added Leo as a watcher.

        Eric, is there a public queue I should add such issues to? For instance, should this issue really be in the KFS public queue? Thanks!

        Show
        James Smith added a comment - Added Leo as a watcher. Eric, is there a public queue I should add such issues to? For instance, should this issue really be in the KFS public queue? Thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            James Smith
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel