Good point. It's not quite obvious what happens with the
root-element-class if a schema-assignment is used.
It is ignored completely.
I attached the root-element-class to the schema because a schema is
reusable and the users shouldn't need do define the class redundantly.
Additionally the schema rules are heavily depending on the container class.
The best solution might be to rename "root-element-class" to
"required-container-class" and add a optional "container-class" attribute
to the configuration point like you suggested.
1. if the configuration point specifies a container-class it has priority.
An instance of that class is created and passed to the schema.
The schema checks if that class is compatible with its
required-container-class.
2. if the configuration point doesn't specifiy a container-class then
the required-container-class of the schema is used.
3. if the schema is assigned afterwards then the original configuration
point
definition determines the container class. The schema
just checks if it is compatible like in case 1.
"required-container-class" even could be an interface. Case 2 would
throw an exception then.
Achim
Knut Wannheden schrieb:
Nice!
I've already got a question :-) Why is in the XML example the
"root-element-class" on the <schema> element? I would have expected it
on the <configuration> element as in the case of a <schema-assignment>
the class of the container object will be given by the referenced
configuration. Also I think the name "root-element-class" is not quite
appropriate as it's not really tied to the root element. (Moreover the
schema may define multiple root elements.)
How about something like:
<configuration-point id="ObjectProviders"
container-interface="java.util.Map"
container-class="java.util.HashMap">
?
--knut
On 11/7/06, Achim Hügen <[EMAIL PROTECTED]> wrote:
Hi,
I've finished a short overview of the changes in the annotation branch:
http://wiki.apache.org/jakarta-hivemind/NewAndNoteworthyFeaturesInAnnotationBranch
Have fun
Achim
