Hi,
Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "Scott Kurz" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 08, 2007 8:32 PM
Subject: [sca-java-integration-branch] issues w/ DataBindingRegistryImpl and
SDO loading
The new DataBindingJavaInterfaceProcessor seems neat ..... thoughI'm
having
a problem in that my SDOs aren't getting converted to/from AXIOM
correctly. The reason has to do w/ DataType construction and this new
processor.
Within my Composite, my component gets loaded before the <import.sdo>
element, and thus the ComponentLoader gets called before ImportSDOLoader.
During the component loader the
DataBindingJavaInterfaceProcessor gets called to process my component's
service intf, which has the @DataType(...DataObject..) annotation on it.
However, the SDODataBinding.introspect()
method (called by DataBindingRegistryImpl.introspectType()) passes on
my
app as it can't find my type in the TypeHelper.
Good catch. I think the order of loading is the element order under
<composite> as we use StAX. You should be able to work around this by
adjusting you SCDL.
I also find another issue: The SDODataBinding needs to access the
HelperContext associated with the composite to perform the correct
instrospection. Unfortunately, it's not passed down from the Loader to
JavaInterfaceProcessor today. We might to have to add DeploymentContext to
the method signatures to support this. (In the code today, we use the
default HelperContext in the SDODataBinding and it's not right.)
The introspection of SDO depends on the TypeHelper today because there's no
annotation or static field in the generated SDO class/interface to tell us
it's from SDO.
I wonder if the answer is more complicated than ensuring ImportSDOLoader
goes first. Wasn't <import.sdo> simply optional before, saving the user
from having to make SDO calls in the SCA app?
Now we won't work without it?
<import.sdo> has never been optional even though we're investigating to see
if it's possible to make it optional. One thought is that we use the
contribution service to get all the XSDs but it might be expensive to
convert all XSDs into SDO model. For generated SDOs, we could collect them
as part of the SDO type introspection.
I think it actually would have still worked for me if it weren't for the
fact that, if we get to the end of DataBindingRegistryImpl.introspectType,
we do a:
dataType.setDataBinding(JavaBeansDataBinding.NAME);
We try to default any unknown type to a POJO.
For me, since I have an SDO DB set on my operation, the mediator code
would
have picked up the operation level DB if the arg/returnType DB was null.
I'm not sure it's a good thing to have this
many ways to set the DB... but I thought I'd mention that.
I plan to move away from providing default databinding for an interface or
method as we can figure out most of the databindings by introspection.
Having a default databinding is confusing. For example, if we cannot
recognize a parameter type to be any known databinding by introspection,
should we treat it as a POJO or the default databinding?
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
