So what happens to the patch on HARMONY-1723.
My opinion is that it is OK. Consider the following: 1. Applications bounded to the RI behavior (e.g. obtaining the descriptors for read-only properties without construction of getter name) won't fail. 2. Construction of the default getter/setter names could be incapsulated in the PropertyDescriptor. For now there's no possibility of getting a descriptor for one read-only/write-only property without constructing its getter/setter name outside of the PropertyDescriptor. 3. Don't think that it is bad if PropertyDescriptor would lookup for reasonable defaults if provided names are invalid. I'd like to hear another opinion. If somebody will disagree I'll make another fix for the TransferHandler, whithout touching beans. On 10/5/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
So what happens to the patch on HARMONY-1723. Do you (Oleg & Alexey) think we should not fix it that way now? Regards, Tim Oleg Khaschansky wrote: > Alexey, > > Agree. I haven't noticed that RI doesn't accept invalid write method. > Then its behavior looks illogical. Actually, I asked about comments > especially because I expected a feedback from beans authors. Thank > you. > > On the other hand, why don't we allow Harmony to accept invalid names > and provide a default replacements for them if there is a set/get/is > method for the specified property? It seems to me more user-friendly > then throw IntrospectionException in this situation. It looks like the > specification doesn't require PropertyDescriptor to throw an exception > in this case. This will also prevent us from breaking applications > that uses this RI behavior. > What is your opinion? > > On 10/5/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: >> Oleg, >> >> > + we need to fix in beans the fact that the following code: >> > new PropertyDescriptor(propertyName, c.getClass(), "1", null); >> > will throw IntrospectionException on Harmony, but will return the >> > valid property descriptor with the getter method on RI. >> > Any thoughts on this? Or should I proceed with a patch for the both >> issues? >> >> I've already written my thoughts about this issue in [1]. In short: I >> don't think we should follow the RI behavior since it is inconsistent. >> Why it accepts invalid read method and throws exception on invalid >> write method? No logic. >> >> [1] >> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] >> >> >> Thanks, >> >> 2006/10/4, Oleg Khaschansky <[EMAIL PROTECTED]>: >> > I found the reason of this failure. It is an IntrospectionException >> > while executing a following method from the TransferHandler class: >> > >> > private PropertyDescriptor getPropertyDescriptor(final JComponent >> c) { >> > PropertyDescriptor result = null; >> > try { >> > result = new PropertyDescriptor(propertyName, c.getClass()); >> > } catch (IntrospectionException e) { >> > >> > } >> > return result; >> > } >> > It tries to get the PropertyDescriptor for the class JButton and >> > property name "insets", but fails because there's no setInsets method. >> > So, flavors array stays uninitialized and getTransferDataFlavors >> > method returns null which is a cause of a NPE. >> > >> > The quick fix for this issue could be changing this method to the >> following: >> > >> > private PropertyDescriptor getPropertyDescriptor(final JComponent >> c) { >> > PropertyDescriptor result = null; >> > try { >> > return result = new PropertyDescriptor(propertyName, >> c.getClass()); >> > } catch (IntrospectionException e) { >> > } >> > try { >> > return result = new PropertyDescriptor(propertyName, >> > c.getClass(), "1", null); >> > } catch (IntrospectionException e) { >> > } >> > return result; >> > } >> > >> > + we need to fix in beans the fact that the following code: >> > >> > new PropertyDescriptor(propertyName, c.getClass(), "1", null); >> > >> > will throw IntrospectionException on Harmony, but will return the >> > valid property descriptor with the getter method on RI. >> > >> > Any thoughts on this? Or should I proceed with a patch for the both >> issues? >> > >> > Thanks, >> > Oleg >> > >> > On 10/4/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: >> > > 2006/10/4, Mark Hindess <[EMAIL PROTECTED]>: >> > > > >> > > > On 4 October 2006 at 15:41, Tim Ellison <[EMAIL PROTECTED]> >> wrote: >> > > > > Excuse the change in subject line... >> > > > >> > > > No problem. I was just cursing myself for having forgotten to >> change >> > > > it. >> > > > >> > > > > Mark Hindess wrote: >> > > > > > With this change, the awt dependencies should now be >> automated for >> > > > > > windows and at least fairly trivial (installing a few >> packages on >> > > > > > Linux[0]). I think it is time we removed the with.awt.swing >> flag. >> > > > > > Anyone object? >> > > > > >> > > > > To the contrary, ditch it. >> > > > > >> > > > > > Please test the current setup with -Dwith.awt.swing=true and >> report any >> > > > > > problems. >> > > > > >> > > > > Problem 1: My machine is too slow running all these tests. >> > > > >> > > > Mine too. And I have wondered if the hourly builds will finish >> within >> > > > the hour now. We really should see if we can avoid the need to >> fork >> > > > for every test. >> > > >> > > I've run the tests on my XP machine, 1 failed >> > > >> > > javax.swing.TransferHandlerTest#testCreateTransferable >> > > >> > > java.lang.NullPointerException at >> > > >> javax.swing.TransferHandlerTest.testCreateTransferable(TransferHandlerTest.java:140) >> >> > > at >> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) >> > > at >> javax.swing.BasicSwingTestCase.runBareSuper(BasicSwingTestCase.java:115) >> > > at javax.swing.SwingTestCase$1.run(SwingTestCase.java:44) at >> > > java.awt.event.InvocationEvent.runAndNotify(InvocationEvent.java:88) >> > > at >> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:77) at >> > > java.awt.EventQueueCore.dispatchEventImpl(EventQueueCore.java:131) at >> > > java.awt.EventQueue.dispatchEvent(EventQueue.java:144) at >> > > >> java.awt.EventDispatchThread.runModalLoop(EventDispatchThread.java:75) >> > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:48) >> > > >> >> -- >> Alexei Zakharov, >> Intel Middleware Product Division >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
