Details

    • Type: Task Task
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      This needs some discussion before being done. It'd break backwards-compatibility with the 1.x series.

      DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21. We're not really testing its direct usage at the moment, and I wonder what reason end-users would have to be invoking its operations to muck around with the "namespace" of a domain object. Currently all descriptors are supporting its operations by extension:

      public interface WebAppDescriptor extends Descriptor, DescriptorNamespace<WebAppDescriptor>

      ...and the methods in question as defined by DescriptorNamespace are:

         public T addDefaultNamespaces();
         public T addNamespace(String name, String value);
         public List<String> getNamespaces();
         public T removeAllNamespaces();

      Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and DescriptorMutableNamespace.

      My feeling is that neither should be part of the API; maybe SPI or just internals.

      Discuss if it's appropriate to remove this and break the backwards-compatibility with the 1.x series. In this case, I'm willing to entertain this exception.

        Issue Links

          Activity

          Hide
          Ken Finnigan
          added a comment -

          Also can't think of a reason why you'd be messing with namespaces when either trying to read items from a Descriptor, or creating them.

          Would it be used to test invalid namespaces throw accurate errors in containers? About the only thing I can think of.

          Would be in favour of it moving to at a minimum SPI, if not just internals.

          Show
          Ken Finnigan
          added a comment - Also can't think of a reason why you'd be messing with namespaces when either trying to read items from a Descriptor, or creating them. Would it be used to test invalid namespaces throw accurate errors in containers? About the only thing I can think of. Would be in favour of it moving to at a minimum SPI, if not just internals.
          Hide
          Ralf Battenfeld
          added a comment -

          Fair question. I remember we discussed this a little bit here:https://community.jboss.org/message/605293#605293

          The common agreement was to provide CRUD operations for the namespaces. I can think of the case that an end user wants to change the url from http:/... to file://.. for validation purposes, or to get rid of the namespaces at all.

          I agree that this is of limited value, except we make a mistake by configuring the namespaces...
          Personally, I would keep it and not to lock-in this. May we also should think that the metadata-parser-plugin could be used outside of the descriptors we generate.

          Show
          Ralf Battenfeld
          added a comment - Fair question. I remember we discussed this a little bit here: https://community.jboss.org/message/605293#605293 The common agreement was to provide CRUD operations for the namespaces. I can think of the case that an end user wants to change the url from http:/... to file:// .. for validation purposes, or to get rid of the namespaces at all. I agree that this is of limited value, except we make a mistake by configuring the namespaces... Personally, I would keep it and not to lock-in this. May we also should think that the metadata-parser-plugin could be used outside of the descriptors we generate.
          Hide
          Dan Allen
          added a comment -

          I think that namespace manipulation is acceptable as a general purpose facility for XML dialects, but perhaps something we want "frozen" for standard descriptors such as web.xml, persistence.xml, etc.

          Thus, another alternative here is to allow concrete descriptors (like WebAppDescriptor) to freeze the namespaces, such that the methods either don't perform any action or throw an exception when manipulation of the namespaces is attempted. The freeze setting would be interweaved by the generator, such that you could recreate a clone of the descriptor into your own package to reenable namespace modification.

          Show
          Dan Allen
          added a comment - I think that namespace manipulation is acceptable as a general purpose facility for XML dialects, but perhaps something we want "frozen" for standard descriptors such as web.xml, persistence.xml, etc. Thus, another alternative here is to allow concrete descriptors (like WebAppDescriptor) to freeze the namespaces, such that the methods either don't perform any action or throw an exception when manipulation of the namespaces is attempted. The freeze setting would be interweaved by the generator, such that you could recreate a clone of the descriptor into your own package to reenable namespace modification.
          Hide
          Andrew Rubinger
          added a comment -

          Perhaps instead of "Freezing" the namespaces we instead allow them to be mutable only in the Descriptor mutable view?

          Show
          Andrew Rubinger
          added a comment - Perhaps instead of "Freezing" the namespaces we instead allow them to be mutable only in the Descriptor mutable view?

            People

            • Assignee:
              Michal Matloka
              Reporter:
              Andrew Rubinger
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: