Bugzilla – Full Text Bug Listing
| Summary: | [metatype] Cardinality violation with cardinality == 0 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jarek Gawor <jgawor> |
| Component: | Compendium | Assignee: | John Ross <jwross> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jwross |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Jarek Gawor
Which version is this? Or is the the latest from HEAD? Why do you think it shouldn't matter if the value contains a comma or not? Within this syntax, a comma is a special character that separates one cardinal value from another. Furthermore, an empty string is a valid String value. See https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1861#c3. How would we know the difference between a meaningless trailing comma and a meaningful one indicating an empty string? Is this rejection something new? Do you know if previous versions didn't reject this? I'm looking at HEAD (git repo that is). I don't know if it is something new. We just haven't run into that before. The 1.1 spec talks about the comma separated list when talking about the default value in metatype and the content attribute. It does not say or imply that the value passed in AD.validate() should also be considered a comma separated list. To me, AD.validate() implies we are passing a single value - not a possible list. (In reply to comment #2) > I'm looking at HEAD (git repo that is). I don't know if it is something new. We > just haven't run into that before. > The 1.1 spec talks about the comma separated list when talking about the > default value in metatype and the content attribute. It does not say or imply > that the value passed in AD.validate() should also be considered a comma > separated list. > To me, AD.validate() implies we are passing a single value - not a possible > list. This all seemed very familiar to me and, fortunately, I was able to find the relevant OSGi and Equinox bugs where this has been discussed rather extensively in the past. https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1843 bug 332161 The resulting behavior is described in bug 332161 comment 4. Tom would agree with you that validate() is (or should be) really for passing a single value (bug 332161 comment 7) but there were complications with maintaining backwards compatibility. In summary, the validate() method will validate both single and multiple values. If the comma in your value is not intended as a special character, it must be escaped with '\'. If it is left unescaped, it will be treated as a special character and multiple cardinal values will be assumed. (In reply to comment #3) > The resulting behavior is described in bug 332161 comment 4. Tom would agree > with you that validate() is (or should be) really for passing a single value > (bug 332161 comment 7) but there were complications with maintaining backwards > compatibility. Just for the record, I favor being able to validate multiple values for the following reasons. First, it enables you to pass the value of the "default" attribute directly as an argument to the validate method. Second, and more importantly, not validating multiple values means the API has no way to check the cardinality constraints. Having heard no objections to the explanation for why it works this way, I'm closing this. Please reopen if any issues remain. |