Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      13

      Description

      In the WebDAV spec a call for the names of the properties is described. A PROPFIND
      is send with the argument "propnames".
      To create a valid response you have to send "only" the names of the properties.
      The problem is that the default constructor is private, so you have to pass NULL
      in every constructor.
      Is the recommended way to pass NULL or should we switch from private to public? Or
      is a Factory/Builder which has access to the private constructor a better
      solution?

        Issue Links

          Activity

          Hide
          daniel_manzke added a comment -

          Example:

          private CreationDate()

          { // For unmarshalling only. }
          Show
          daniel_manzke added a comment - Example: private CreationDate() { // For unmarshalling only. }
          Hide
          mkarg added a comment -

          Can you please post a link to an example in the spec that outlines the XML
          format that you want to create but just cannot?

          Show
          mkarg added a comment - Can you please post a link to an example in the spec that outlines the XML format that you want to create but just cannot?
          Hide
          mkarg added a comment -

          I am assuming that you mean this example in the specification:

          9.1.4 Example - Using 'propname' to Retrieve All Property Names
          (http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.4)

          The example shows that the correct response to a PROPFIND request on
          <propname/> is a list of all names of supported properties. The names have to
          be provided as XML elements, what is rather weird as the typical XML user
          expects to include them as a simple blank separated values list instead of an
          elements sequence.

          The problem is that the same specification mandates that each property must
          contain a particular, valid value, e. g. <creationdate> must surround a real
          date value. It makes sense to prevent creation if "empty" elements, since those
          are most typically created by fault instead of by intention.

          So the title of the bug report is misleading. It is absolutely correct by
          intention, that the default constructors are private, as this prevents errors.

          The actual problem is that there shall be support for valid <propname/>
          request's <prop> response. Due to this, I am replacing the title of this bug
          report.

          The question is, how it shall be possible to create empty property elements to
          fulfil the need to just list them up, while still be able to keep backwards
          compatibility and keep the existing safety to prevent unwanted empty elements.

          A proposal could be to actually make the default constructors public as you
          said, while still keeping the null check in the with-value-constructor
          ("builder constructor"). This would serve both purposes but still keep at most
          safety: You can omit the value, but if you provide one, it must not be null.
          The JavaDoc of the default constructor then should contain a note that it must
          only be used in exactly that sole case, while in all other cases the builder
          constructor (including a valid value) has to be used.

          Would this solution look like what you like to get? Do you see a different
          solution?

          Show
          mkarg added a comment - I am assuming that you mean this example in the specification: 9.1.4 Example - Using 'propname' to Retrieve All Property Names ( http://www.webdav.org/specs/rfc4918.html#rfc.section.9.1.4 ) The example shows that the correct response to a PROPFIND request on <propname/> is a list of all names of supported properties. The names have to be provided as XML elements, what is rather weird as the typical XML user expects to include them as a simple blank separated values list instead of an elements sequence. The problem is that the same specification mandates that each property must contain a particular, valid value, e. g. <creationdate> must surround a real date value. It makes sense to prevent creation if "empty" elements, since those are most typically created by fault instead of by intention. So the title of the bug report is misleading. It is absolutely correct by intention, that the default constructors are private, as this prevents errors. The actual problem is that there shall be support for valid <propname/> request's <prop> response. Due to this, I am replacing the title of this bug report. The question is, how it shall be possible to create empty property elements to fulfil the need to just list them up, while still be able to keep backwards compatibility and keep the existing safety to prevent unwanted empty elements. A proposal could be to actually make the default constructors public as you said, while still keeping the null check in the with-value-constructor ("builder constructor"). This would serve both purposes but still keep at most safety: You can omit the value, but if you provide one, it must not be null. The JavaDoc of the default constructor then should contain a note that it must only be used in exactly that sole case, while in all other cases the builder constructor (including a valid value) has to be used. Would this solution look like what you like to get? Do you see a different solution?
          Hide
          mkarg added a comment -

          Must be fixed before Releases 1.2 and 2

          Show
          mkarg added a comment - Must be fixed before Releases 1.2 and 2
          Hide
          mkarg added a comment -

          Fixed since 1.1.1

          Fixed according to above proposal: Properties' default constructors are default
          now, JavaDoc indicates correct usage, builder-constructor still checking for
          null.

          Show
          mkarg added a comment - Fixed since 1.1.1 Fixed according to above proposal: Properties' default constructors are default now, JavaDoc indicates correct usage, builder-constructor still checking for null.

            People

            • Assignee:
              mkarg
              Reporter:
              daniel_manzke
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: