Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of bardweller@gmail.com
 designates 209.85.219.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=dWp4P9hHw86ynZobvtf1dhW+gxHEmnZb1LakRVWeW3S/CGi3DJK5gcvOR4VkYulil4
         VgqHjHnW2KwKFWQnBN+sl/h6/+H9z43SaNIC/SeeLRYTCqlr/35gfb7jzvWzP+L62kfz
         TL6HKmzqzxa/5vLMvoUnC8S6dPYgg4Y6ZVf+A=
MIME-Version: 1.0
In-Reply-To: <2CF2153B-E9E3-43FD-A672-66BD72AB9669@yahoo.com>
References: <2CF2153B-E9E3-43FD-A672-66BD72AB9669@yahoo.com>
Date: Sun, 10 Jan 2010 21:22:02 +0000
Message-ID: <ec2fe6dd1001101322w31de28bn924b082152b858d5@mail.gmail.com>
Subject: Re: Blueprint NamespaceHandler issues
From: The Dweller <bardweller@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d59ec50cc1a6047cd6036a

--0016e6d59ec50cc1a6047cd6036a
Content-Type: text/plain; charset=ISO-8859-1

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 <david_jencks@yahoo.com>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
>
>

--0016e6d59ec50cc1a6047cd6036a--