See inline.
Simon
kelvin goodson wrote:
> There has been a few occasions in the SDO spec meetings where issues
> associated with raising exceptions have been resolved in favour of not
> requiring the implementer to incur the performance overhead of
> exception
> translation or decoration. There are no exceptions defined by the SDO
API,
> and only runtime exceptions can surface through the interface.
>
> In this situation the schema has been written in error such that the
type
> was specified incorrectly, and therefore when assigning an instance of
the
> intended SDO Type to a Property of the erroneous Type then the expected
> result is a ClassCastException.
>
> We can discuss the merits of catching and rethrowing decorated or
translated
> exceptions in general, but this is widespread through Tuscany's SDO
(and I
> would imagine also through other implementations given the spec
> discussions), and would result I am sure in performance degradation.
>
A question of clarification. Was the specified type xsd:Name a valid
type that was not what the user intended, or was it an invalid
(nonexistent)
type? If the former, then a ClassCastException at the point of
assignment
seems like an appropriate diagnostic. If the latter (and this was my
impression, perhaps incorrectly), then a more friendly diagnostic could
be
produced at schema load time or validation time, indicating the reference
to a nonexistent type.
Regarding the overhead of catching and rethrowing exceptions, it's my
belief
that adding a try/catch block is effectively free unless an exception is
actually caught. In that case, it's usually an error path for which I
would
not expect performance to be an issue. I realise that not all exceptions
represent "hard errors", but I think a ClassCastException does.
Simon
> Regards, Kelvin.
>
> On 20/02/2008, Simon Nash <[EMAIL PROTECTED]> wrote:
>> See inline.
>>
>> Simon
>>
>> wang feng wrote:
>>> It's OK,Thanks Raymond.
>>>
>>> Thanks,
>>> wangfeng
>>>
>>>
>>> On 2008-02-20, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I debugged your test case and it turned out the problem is in your
test
>> case. There is a dangling type reference in helloworld.wsdl:
>>>> <wsdl:types>
>>>> <schema elementFormDefault="qualified" targetNamespace="
>> http://helloworld"; xmlns="http://www.w3.org/2001/XMLSchema";>
>>>> <element name="getGreetings">
>>>>
>>>> <complexType>
>>>>
>>>> <sequence>
>>>>
>>>> <element name="name" type="xsd:Name"/>
>>>>
>>>> </sequence>
>>>>
>>>> </complexType>
>>>>
>>>> </element>
>>>>
>>>> It should be: <element name="name" type="tns:Name"/>.
>>>>
>>>> After fixing the issue, I can run it successfully with the
import.sdostatement.
>>>>
>> Can we track this as a JIRA? A simple user error like this should not
>> produce a ClassCastException deep in EMF.
>>
>> Simon
>>
>>>> Thanks,
>>>>
>>>> Raymond
>>>>
>>>> ----- Original Message -----
>>>> From: "wang feng" <[EMAIL PROTECTED]>
>>>> To: <tuscany-dev@ws.apache.org>
>>>> Sent: Tuesday, February 19, 2008 5:04 PM
>>>> Subject: Re: Re: How to use SDO in tuscany sca?
>>>>
>>>>
>>>>> I add the element 'import.sdo' in the composite,but the sample
throws
>> another exception.
>>>>> Exception in thread "main" java.lang.ClassCastException: The value
of
>> type 'class org.apache.tuscany.sdo.impl.DynamicDataObjectImpl' must be
of
>> type 'class java.lang.String'
>>>>> at
>>
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableStatic.validate
>> (EStructuralFeatureImpl.java:2195)
>>>>> at
>>
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet
>> (EStructuralFeatureImpl.java:2116)
>>>>> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(
>> BasicEObjectImpl.java:709)
>>>>> at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(
>> DynamicDataObjectImpl.java:160)
>>>>> at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(
DataObjectImpl.java
>> :1468)
>>>>> at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(
>> BasicEObjectImpl.java:654)
>>>>> at org.apache.tuscany.sdo.impl.DataObjectImpl.set(
DataObjectImpl.java
>> :146)
>>>>> at org.apache.tuscany.sdo.impl.DataObjectImpl.set(
DataObjectImpl.java
>> :106)
>>>>> at
>>>>> org.apache.tuscany.sca.databinding.sdo.SDOWrapperHandler.setChild
(
>> SDOWrapperHandler.java:71)
>>>>> at
>>
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform
>> (Input2InputTransformer.java:131)
>>>>> at
>>
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform
>> (Input2InputTransformer.java:1)
>>>>> at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(
>> MediatorImpl.java:73)
>>>>> at
>>
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform
>> (DataTransformationInterceptor.java:175)
>>>>> at
>>
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke
>> (DataTransformationInterceptor.java:72)
>>>>> at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
>> JDKInvocationHandler.java:261)
>>>>> at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(
>> JDKInvocationHandler.java:149)
>>>>> at $Proxy5.getGreetings(Unknown Source)
>>>>> at helloworld.HelloWorldClient.test(HelloWorldClient.java:53)
>>>>> at helloworld.HelloWorldClient.main(HelloWorldClient.java:39)
>>>>>
>>>>> Is something wrong? Where can I found a sample whith dynamic SDO?
>>>>>
>>>>> Thanks,
>>>>> wangfeng
>>>>>
>>>>>
>>>>> On 2008-02-19, Scott Kurz <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Wang,
>>>>>>
>>>>>> I'm guessing the problem is probably that you need to register
>>>>>> your
>>>>>> app types with the appropriate context established by the Tuscany
>>>>>> runtime.
>>>>>>
>>>>>> Tuscany typically does this automatically, now, for static
SDO. For
>>>>>> dynamic SDO (i.e. DataObject), you would currently put something
like
>>>>>> this in your SCDL ( *.composite) file:
>>>>>>
>>>>>> <composite ...
>>>>>> xmlns:dbsdo="
>> http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>>>>> ....>
>>>>>>
>>>>>> <dbsdo:import.sdo location="wsdl/helloworld.wsdl"/>
>>>>>>
>>>>>> (I looked in your zip and you don't seem to use the types in the
XSD,
>>>>>> so I pointed to the WSDL instead... but you can have as multiple
>>>>>> <import.sdo> elements).
>>>>>>
>>>>>> This relation between SCA and SDO scopes is defined by Tuscany,
>>>>>> not
a
>>>>>> spec, at the moment.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> On Feb 18, 2008 9:15 AM, wang feng <[EMAIL PROTECTED]> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I do a sample which has a parameter's type is DataObject,and
>> deploy the component with webservice.
>>>>>>> When I invoke the service ,throws an error.
>>>>>>> Is my usage wrong?
>>>>>>>
>>>>>>> My sample like this.
>>>>>>>
>>>>>>> helloworld.composite
>>>>>>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>>>>>>> targetNamespace="http://helloworld";
>>>>>>> xmlns:hw="http://helloworld";
>>>>>>> name="helloworldws">
>>>>>>> <component name="HelloWorldServiceComponent">
>>>>>>> <implementation.java class="helloworld.HelloWorldImpl" />
>>>>>>> <service name="HelloWorldService">
>>>>>>> <interface.wsdl interface="
>> http://helloworld#wsdl.interface(HelloWorld)" />
>>>>>>> <binding.ws/>
>>>>>>> </service>
>>>>>>> </component>
>>>>>>> </composite>
>>>>>>>
>>>>>>> HelloWorldImpl.java
>>>>>>> @Service(HelloWorldService.class)
>>>>>>> public class HelloWorldImpl implements HelloWorldService {
>>>>>>> public String getGreetings(DataObject name) {
>>>>>>> return "Hello " + name.getString("first") + " " +
>> name.getString("last");
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> You can download the full testcase on
>> http://www.blogjava.net/Files/wangfeng/src.zip
>>>>>>> Thanks
>>>>>>> Wang Feng
>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
