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]

Reply via email to