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]
