Thanks,
Frank
"Raymond Feng" <[EMAIL PROTECTED]> wrote on 03/12/2007 07:37:50 PM:
Hi, Frank.
I now see the requirements to recognize the SDO generated
classes/interfaces
before the SDO TypeHelper is populated. As a result, I would prefer not
to
rely on TypeHelper.getType(). In my case, we want to introspect java
types
to find the usages of SDO generated classes/interfaces in the SCA
composite
and populate the corresponding HelperContext instead of requiring a
<import.sdo> upfront. Does it make sense?
Thanks,
Raymond
----- Original Message -----
From: "Frank Budinsky" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, February 23, 2007 3:56 PM
Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of
TypeHelperImpl.getType(Class)
> 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]
>
---------------------------------------------------------------------
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]