]
Michal Matloka reassigned SHRINKDESC-116:
-----------------------------------------
Assignee: Michal Matloka (was: Ralf Battenfeld)
Descriptors 2.0 module BeansDescriptor API: common operations
difficult, API confusing
--------------------------------------------------------------------------------------
Key: SHRINKDESC-116
URL:
https://issues.jboss.org/browse/SHRINKDESC-116
Project: ShrinkWrap Descriptors
Issue Type: Feature Request
Environment: java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Reporter: Craig Ringer
Assignee: Michal Matloka
Labels: alternative, arquillian, beans, beans.xml, descriptors, shrinkwrap
The API for BeansDescriptor in the Descriptors 2.0 module
(org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee:jar:2.0.0-alpha-2) is
confusing and hard to use for simple cases. It needs revision.
The distinction between BeansDescriptor.createAlternatives() and
BeansDescriptor.getOrCreateAlternatives() isn't clear. Does the former unconditionally
replace any existing alternatives entry?
There's no obvious .replace(oldBean, newBean) to swap alternatives. The descriptor
needs simple methods for:
- Removing an alternative
- Replacing an alternative
- Adding an alternative
It almost appears that the descriptor module is trying to handle multiple
<alternatives/> entries, if that's the purpose of
BeansDescriptor.getAllAlternatives(). Weld doesn't permit multiple alternatives, as a
test with multiple alternatives entries will show:
org.jboss.weld.exceptions.DefinitionException: WELD-001203 <alternatives> can only
be specified once, but appears multiple times:
vfs:/content/demo.jar/META-INF/beans.xml@6
... and as far as I can tell the beans.xml xsd backs that up:
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd
It doesn't make sense for the descriptors module to produce invalid descriptors;
someone testing Weld code, JBoss descriptor loading, etc would use hand-crafted
descriptors or descriptors produced using the XML APIs, not something like shrinkwrap
descriptors. It really only needs to handle well-formed descriptors and should handle
common tasks quickly and easily.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: