Details

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

      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.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            kenfinni 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
            kenfinni 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
            rbattenfeld 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
            rbattenfeld 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.j.allen 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.j.allen 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
            alrubinger 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
            alrubinger 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:
                mmatloka Michal Matloka
                Reporter:
                alrubinger Andrew Rubinger
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Development