[
https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl...
]
Dan Allen commented on SHRINKDESC-113:
--------------------------------------
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.
Move DescriptorNamespace out of the Public API
----------------------------------------------
Key: SHRINKDESC-113
URL:
https://issues.jboss.org/browse/SHRINKDESC-113
Project: ShrinkWrap Descriptors
Issue Type: Task
Reporter: Andrew Rubinger
Assignee: Andrew Rubinger
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:
{code}public interface WebAppDescriptor extends Descriptor,
DescriptorNamespace<WebAppDescriptor>{code}
...and the methods in question as defined by DescriptorNamespace are:
{code}
public T addDefaultNamespaces();
public T addNamespace(String name, String value);
public List<String> getNamespaces();
public T removeAllNamespaces();{code}
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira