inline...
On Jan 10, 2010, at 1:22 PM, The Dweller wrote:
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.
basically I want to make what you describe as a "trick" work better,
more often. In a related issue I don't see why the root element
should need to be in the blueprint namespace if an appropriate
NamespaceHandler is registered. xbean-spring has been used in spring
for years by projects such as activemq to do stuff like this. Since
we might have an opportunity to make it work more smoothly in
blueprint.... I think this is a good time to discuss it.
Anyway.... here are some plans that should give the same bunch of
metadata, in various combinations of blueprint and (sample) xbean-
blueprint configurations:
pure blueprint:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";>
<!-- tests using nested beans -->
<bean id="restaurant"
class="org.apache.xbean.blueprint.example.RestaurantService">
<property name="serviceName">
<bean class="javax.xml.namespace.QName">
<argument value="http://acme.com"/>
<argument value="xyz"/>
<argument value="foo"/>
</bean>
</property>
<property name="favourite">
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Salami" />
<property name="cheese" value="Edam" />
<property name="size" value="17" />
</bean>
</property>
<property name="dinnerMenu">
<list>
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Ham" />
<property name="cheese" value="Mozzarella" />
<property name="size" value="15" />
</bean>
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Eggs" />
<property name="cheese" value="Mozzarella" />
<property name="size" value="16" />
</bean>
</list>
</property>
<property name="snackMenu">
<set>
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Tofu" />
<property name="cheese" value="Parmesan" />
<property name="size" value="6" />
</bean>
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Prosciutto" />
<property name="cheese" value="Blue" />
<property name="size" value="8" />
</bean>
</set>
</property>
<property name="lunchMenu">
<list>
<bean class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Chicken" />
<property name="cheese" value="Brie" />
<property name="size" value="17" />
</bean>
</list>
</property>
</bean>
</blueprint>
nearly-pure xbean-blueprint (I think have the root element be in the
foreign namespace should work)
<b:blueprint xmlns:b="http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:p="http://xbean.apache.org/schemas/pizza";
xmlns:foo="http://acme.com";>
<p:restaurant b:id="restaurant"
p:serviceName="foo:xyz"
p:uri="http://cheese.com";>
<p:dinnerMenu>
<p:pizza p:myTopping="Ham" p:cheese="Mozzarella" p:size="15"/>
<p:pizza p:myTopping="Eggs" p:cheese="Mozzarella" p:size="16"/>
</p:dinnerMenu>
<p:lunchMenu>
<p:pizza p:myTopping="Chicken" p:cheese="Brie" p:size="17"/>
</p:lunchMenu>
<p:snackMenu>
<p:pizza p:myTopping="Tofu" p:cheese="Parmesan" p:size="6"/>
<p:pizza p:myTopping="Prosciutto" p:cheese="Blue" p:size="8"/>
</p:snackMenu>
<p:favourite>
<p:pizza p:myTopping="Salami" p:cheese="Edam" p:size="17"/>
</p:favourite>
</p:restaurant>
</b:blueprint>
mixed:
<b:blueprint xmlns:b="http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:foo="http://acme.com";>
<p:restaurant b:id="restaurant" xmlns:p="http://xbean.apache.org/schemas/pizza
"
p:serviceName="foo:xyz">
<p:dinnerMenu>
<p:pizza p:myTopping="Ham" p:cheese="Mozzarella" p:size="15"/>
<b:bean class="org.apache.xbean.blueprint.example.PizzaService">
<b:property name="topping" value="Eggs"/>
<b:property name="cheese" value="Mozzarella"/>
<b:property name="size" value="16"/>
</b:bean>
</p:dinnerMenu>
<p:snackMenu>
<p:pizza p:myTopping="Tofu" p:cheese="Parmesan" p:size="6"/>
<p:pizza p:myTopping="Prosciutto" p:cheese="Blue" p:size="8"/>
</p:snackMenu>
<p:lunchMenu>
<b:bean xmlns=""
class="org.apache.xbean.blueprint.example.PizzaService">
<b:property name="topping" value="Chicken"/>
<b:property name="cheese" value="Brie"/>
<b:property name="size" value="17"/>
</b:bean>
</p:lunchMenu>
<p:favourite>
<bean xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
class="org.apache.xbean.blueprint.example.PizzaService">
<property name="topping" value="Salami"/>
<property name="cheese" value="Edam"/>
<property name="size" value="17"/>
</bean>
</p:favourite>
</p:restaurant>
</b:blueprint>
If you want to look further, the code is at
https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-blueprint
The xml above is from the unit tests.
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.
Hmm.... I wasn't really aware that you were supposed to be able to use
your own metadata classes, since ParserContext has the method to
create them for you. Could be useful.....
So, it seems that the two reasonable solutions would be to get the
spec to require metadata implementations to implement equals and
hashcode appropriately, or to compare metadata object myself. The
former seems more reliable to me, as I'd guess that such non-aries
metadata classes might have information in them that is not exposed by
the various metadata interfaces that would lead an external equals
method to give the wrong result. Is this a reasonable fear? Its
certainly easy enough to write an external equals method.
thanks!
david jencks
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
