Just a couple of quick responses, I'll look a bit more tomorrow.. 1. ARIES-111 In general namespaces are enforced by the schema, and outside of the parseElement call, BeanMetata data has its namespace checked & handled correctly. The parseElement call would only be invoked by a custom namespace handler, at which point you are now parsing a non-blueprint-namespaced element (or attribute), and it's content is under your control. That's to say the namespace handler should know what content it expects, blueprint or not, and had to supply a schema to that effect back to the parser.
The current approach does not lend well though to being able to ask the parser to 'please just handle this, and anything inside it', which would make sense if you were including xsd:any within your element from your custom schema, _and_ that you intended that 'any' content to contain yet more blueprint, or blueprint-instance-extended-namespace content.. I'd be interested in how you'd use nested blueprint metadata like this, as I suspect currently that would involve a bean processor, or component definition registry processor (or, just possibly a rather twisted passthrumetadata, or componentfactorymetadata). So I can see that there could be value to either adding a new method to the parser context, or updating the current one. The current method however does allow the slight trick where you can take a non blueprint element, and have it parse as if it were a given blueprint element, by passing the appropriate metadata and the element, which can be an interesting way to get blueprint to give you back information you wish to use. For example, you could have an 'CustomBeanMetadata' element that you declare with the appropriate schema to accept the content of a regular bean, plus a few other bits you care for. When the ns handler is invoked for the CustomBeanMetadata element, you can pass it back to the parsercontext, asking it to be parsed as a bean. Then you can modify the data, or perform whatever action the ns handler was there for, again I'm interested in any scenarios you think of around this sort of usage. 2. ARIES-110 I wonder for the equals/hashcode case what you would do if you encountered implementations of the Metadata interfaces that were not the org.apache.. impls. As any other namespace handler, or component definition registry processor, could be creating instances of the blueprint api interfaces that are not 'our' impls, and which may not implement a sensible equals / hashcode. Regards, Ozzy On Sun, Jan 10, 2010 at 6:32 PM, David Jencks <[email protected]>wrote: > 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 > >
