On 4/16/07, Raymond Feng <[EMAIL PROTECTED]> wrote:

Hi, Simon.

I think you hit the point. We still need to flush out the complete design
on
how to scope SDO metadata and how to provide access to the SCA components.
At this moment, I register the SDO types with the default helper context
too
(HelperProvider.getDefaultContext()). Please let me know which test case I
can use to further investigate.

Thanks,
Raymond

----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" <tuscany-dev@ws.apache.org>
Sent: Monday, April 16, 2007 2:04 PM
Subject: Use of HelperContext to indetify SDO databinding?


> Static SDO used in the databinding tests with the Axis2 binding are not
> being successfully identified as SDOs.
> In SDODataBinding.introspect() one of the tests use to identify and SDO
> from
> a Java type is as follows
>
>        HelperContext context = HelperProvider.getDefaultContext();
>
>        ...
>
>        // FIXME: We need to access HelperContext
>        Type type = context.getTypeHelper().getType(javaType);
>        if (type == null) {
>            return false;
>        }
>
> However when the ImportSDO functionality runs it associates the importer
> with a HelperContext from the helperContextRegistry.
>
>           helperContext = helperContextRegistry.getHelperContext(id);
>
> This doesn't look right to me as I expect different HelperContexts will
be
> used. I can't work out how to get to the helperContextRegistry from the
> SDODataBinding (and it's getting late) but if someone who knows
> databindings
> could take a look and confirm or not whether this is an issue I can take
a
> look tomorrow.
>
> Regards
>
> Simon
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hi Raymond

Sorry about the delay, I had to go do something else yesterday. Anyhow I
tracked down the problem this morning. The CompositeProcessor resolves the
artifacts in the composite in the wrong order. I.e. it resolves components
before it has resolves the extensions, e.g. SDO imports, that the components
depend on.

Moving the extension processing loop above the component processing loop in
CompositeProcessor.resolve works for me. Am just testing my build etc. to
make sure there are no detrimental effects but will check this in when done.

Regards

Simon

Reply via email to