Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-3054

Deprecate RepositoryService.getPropertyInfo method

    Details

      Description

      I would like to deprecate and ultimately remove the RepositoryService.getPropertyInfo method and extend RepositoryService.getItemInfos to take over that functionality. getItemInfos would thus change to

      /**

      • Method used to 'batch-read' from the persistent storage. It returns the
      • <code>ItemInfo</code> for the given <code>ItemId</code> as the first
      • element in the <code>Iterator</code>. In addition the iterator may contain
      • arbitrary <code>ItemInfo</code>s.
        */
        public Iterator<? extends ItemInfo> getItemInfos(SessionInfo sessionInfo, ItemId itemId) throws ItemNotFoundException, RepositoryException;
      1. JCR-3054.patch
        32 kB
        Michael Dürig

        Activity

        Hide
        Michael Dürig added a comment -

        Tentative patch

        Show
        Michael Dürig added a comment - Tentative patch
        Hide
        Michael Dürig added a comment -

        tentative patch

        Show
        Michael Dürig added a comment - tentative patch
        Hide
        angela added a comment -

        i am fine with deprecating the method.

        the only thing that i was thinking of was the question of the same-name node + property
        feature which is allowed since jcr 283. this used to be a problem in the jcr-remoting
        since on the server-side there - up to now - no possibility to distinguish them path-wise.
        (see JCR-1616)... but since the spi-ItemID itself is sufficient to avoid any ambiguity,
        the proposed solution should not do any harm (au contraire).

        Show
        angela added a comment - i am fine with deprecating the method. the only thing that i was thinking of was the question of the same-name node + property feature which is allowed since jcr 283. this used to be a problem in the jcr-remoting since on the server-side there - up to now - no possibility to distinguish them path-wise. (see JCR-1616 )... but since the spi-ItemID itself is sufficient to avoid any ambiguity, the proposed solution should not do any harm (au contraire).
        Hide
        Michael Dürig added a comment -

        Fixed at revision 1159182

        Show
        Michael Dürig added a comment - Fixed at revision 1159182

          People

          • Assignee:
            Michael Dürig
            Reporter:
            Michael Dürig
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development