I've been working on converting xbean-spring to xbean-blueprint and
have run into a couple of issues that would be more easily fixed in
blueprint. I don't see any bad effects from the changes I'm proposing
but since I'm not that familiar with blueprint wanted to discuss them
before committing.
1. (ARIES-111). ParserContext.parseElement currently requires you to
specify very precisely the type you expect an element to parse into,
and is inconsistent about whether it checks that the element is in the
blueprint namespace and whether it looks for suitable
NamespaceHandlers if it is not. For instance asking for a
BeanProperty does check for blueprint namespace whereas asking for
BeanMetadata does not. There might well be a more general approach
but for my purposes simply allowing Metadata.class as the desired type
and feeding the request to Parser.parseValueGroup parses all blueprint
elements I need and feeds the request to the appropriate
NamespaceHandler.
2. (ARIES-110) equals/hashcode methods on Metadata classes. xbean-
blueprint does some fancy stuff with maps that involve figuring out
whether a key is already present in a map. This means you have to be
able to figure out when keys are "equal". I think this makes sense
for a few metadata types so I'm proposing implementing the methods in
these:
RefMetadataImpl
ValueMetadataImpl
ServiceReferenceMetadataImpl
ReferenceMetadataImpl
This equality test would be fairly easy to implement in the
NamespaceHandler rather than the classes, so if people think that
equals should mean == for these I won't object.
Comments?
thanks
david jencks
