Raymond,
Yes, "null" is returned if it's not an SDO type. I'll try to get a more
efficient implementation (even if not the final solution) in place soon.
Frank.
"Raymond Feng" <[EMAIL PROTECTED]> wrote on 02/23/2007 05:05:37 PM:
Hi,
The SCA databinding code introspects java class to recognize a
SDO-generated
interface/class and get the associated type in a performed way. Yes, I
can
leave it to the SDO impl and I'll use TypeHelper.getType(Class). I
assume
"null" will be returned if the class/interface is not SDO.
Thanks,
Raymond
----- Original Message -----
From: "Frank Budinsky" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, February 23, 2007 1:57 PM
Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
TypeHelperImpl.getType(Class)
> Hi Raymond,
>
> Can you please explain the requirement? Why do you need the type name
and
> why do you instrospect the class? If you want the Type, can't you just
> call TypeHelper.getType(Class) and leave it up to the SDO impl to do
it?
>
> Thanks,
> Frank.
>
> "Raymond Feng" <[EMAIL PROTECTED]> wrote on 02/23/2007 03:55:00 PM:
>
>> Hi, Frank.
>>
>> We have checked in the code for SCA databinding to introspect a
> generated
>> SDO java class. It will be nice to get a fix from SDO. I guess adding
a
>> public static field to the generated classes/interfaces will help us
>> recognize it and get the type name. For example,
>>
>> public static final javax.xml.namespace.QName _SDO_TYPE = new
>> javax.xml.namespace.QName("http://customer";, "Customer");
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Frank Budinsky (JIRA)" <[email protected]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Tuesday, February 13, 2007 4:29 PM
>> Subject: [jira] Commented: (TUSCANY-1110) Improve the performance of
>> TypeHelperImpl.getType(Class)
>>
>>
>> >
>> > [
>> > https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.
>>
> atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12472943]
>> >
>> > Frank Budinsky commented on TUSCANY-1110:
>> > -----------------------------------------
>> >
>> > Yang, can you explain more about your idea?
>> >
>> > I also have a couple of ideas for how to speed up
>> > TypeHelper.getType(Class):
>> >
>> > 1) when we move a Java5 dependency, we should generate an
annotation
> in
>> > the interface, which we could use at runtime to find the Type. The
> exact
>> > format of the annotation depends on an SDO 3 feature to support
Java
>> > metadata annotations, which the SDO collaboration is currently
>> > considering.
>> > 2) before Java5, we could possibly do something like this:
>> > step 1) determine the class name from the provided Class.
>> > step 2) mangle the name to determine the impl class name
(e.g.,
>> > org.example.Foo -> org.example.impl.FooImpl)
>> > step 3) create an instance and then call getType() - or better
> yet,
>> > we could change the generator pattern to generate a static method
that
>
>> > returns the type - and then call it.
>> >
>> > I'm sure there are also other possible ways to do this, but the
> question
>> > is what's the priority for this? Does anyone know if the current
>> > performance of this method is a concern that needs immediate
> attention?
>> >
>> >> Improve the performance of TypeHelperImpl.getType(Class)
>> >> --------------------------------------------------------
>> >>
>> >> Key: TUSCANY-1110
>> >> URL:
> https://issues.apache.org/jira/browse/TUSCANY-1110
>> >> Project: Tuscany
>> >> Issue Type: Improvement
>> >> Components: Java SDO Implementation
>> >> Affects Versions: Java-SDO-Mx
>> >> Reporter: Raymond Feng
>> >> Fix For: Java-SDO-Mx
>> >>
>> >>
>> >> In the SDO databinding for SCA, we need to introspect a java
>> >> class/interface to figure out the corresponding SDO type. Looking
> into
>> >> the code, there is a TODO comment:
>> >> //TODO more efficient implementation ... this is a really bad one!
>> >> Do you plan to provide a more efficient impl :-)?
>> >> Thanks,
>> >> Raymond
>> >
>> > --
>> > This message is automatically generated by JIRA.
>> > -
>> > You can reply to this email to add a comment to the issue online.
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
---------------------------------------------------------------------
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]
