Home » Archived » Visual Editor (VE) » Clarifications on using BeanInfo customizers?
| Clarifications on using BeanInfo customizers? [message #90133] |
Sun, 08 May 2005 19:57  |
Eclipse User |
|
|
|
Originally posted by: no.ddress.here
Just starting to import a number of custom beans.
Couple of questions:
1) first off, since the SwingBeanInfo class has disappeared from dt.jar
in Java 5.0, is there a recommended alternative to SwingBeanInfo - a
preferred BeanInfo support class?
2) if my BeanInfo contains custom property editors, seems that VE does
not introspect the bean for properties that do not have customizers.
For example, my bean (an extension of JLabel) specifies a property
editor for get/setLineWeight and that does show up in VE's property
sheet along with the standard JLabel properties. My bean also has
standard named is/setLineEnabled methods. Since there is no need for a
lineEnabled property editor class, the lineEnabled property is not
explicitly defined in the beaninfo. While other visual editors - Jigloo
specifically - automatically find and show both properties, using a
default boolean editor for lineEnabled, the lineEnabled property does
not show up in the VE property sheet.
Is this expected behavior for VE? Must I list all custom properties if
any one has a custom editor? Or is VE looking for something in the
beaninfo to key it to also introspect the bean?
3) Is there something special I need to provide to enable use of a bean
customizer class?
In other visual editors, such as Jigloo, a double click on the bean in
the design editor will start the customizer class. In VE, double
clicking only lets me change the label text. The toolbar button
"Customize Java Bean" seems permanently disabled.
Again, is this expected behavior? How should this work?
Thanks.
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90194 is a reply to message #90133] |
Mon, 09 May 2005 10:02  |
 Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald Rosenber,
> 2) if my BeanInfo contains custom property editors, seems that VE does
> not introspect the bean for properties that do not have customizers.
All properties are included irrespective of property editors. The
problem I think is because you are trying to have one property explicit
and others implicit and this is not allowed - it is either all explicit
or all implicit.
> For example, my bean (an extension of JLabel) specifies a property
> editor for get/setLineWeight and that does show up in VE's property
> sheet along with the standard JLabel properties. My bean also has
> standard named is/setLineEnabled methods. Since there is no need for a
> lineEnabled property editor class, the lineEnabled property is not
> explicitly defined in the beaninfo. While other visual editors - Jigloo
> specifically - automatically find and show both properties, using a
> default boolean editor for lineEnabled, the lineEnabled property does
> not show up in the VE property sheet.
> Is this expected behavior for VE?
Yes, and the VE is following the JavaBeans specification. Page 62 that
describes the API for getPropertyDescriptors() states:
"Returns: an array of PropertyDescriptors describing the editable
properties supported by this bean. May return null if the information
should be obtained by automatic analysis".
Our reading of this is that null means "find automatically" and not null
means "here they are". Once you provide your lineWeight you are saying
"here they are" and we don't go and look for any more - you must provide
the fully inclusive set.
> Must I list all custom properties if
> any one has a custom editor? Or is VE looking for something in the
> beaninfo to key it to also introspect the bean?
The properties must all be there. You don't need to provide a custom
editor for your lineEnabled property as it is boolean so the VE will use
the correct editor for booleans, so you just return an array with
them all there that you want to see. If there are any inherited ones
you want to see this is done with the getAdditionalBeanInfo().
> 3) Is there something special I need to provide to enable use of a bean
> customizer class?
>
> In other visual editors, such as Jigloo, a double click on the bean in
> the design editor will start the customizer class. In VE, double
> clicking only lets me change the label text. The toolbar button
> "Customize Java Bean" seems permanently disabled.
Customizers should work - I just re-ran the test we have where we do
various combinations of an AWT customizer and a Swing one and it worked
OK. Looking at the code the action would be disabled if no customizer
was returned, or the one returned couldn't be found. Is the customizer
class that your BeanInfo returns maybe requiring stuff that isn't in the
classpath ? Is there anything in the ErrorLog ? If not then open a
bugzilla with as much details as you can including a repeatable test
case and we'll take a look. If you are worried about posting source
code to the bugzilla mention this on the bugzilla request and we'll find
a way to get the source and test it.
Best regards,
Joe Winchester
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90253 is a reply to message #90194] |
Mon, 09 May 2005 18:14 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d5ncuf$gf6$1@news.eclipse.org>, winchest@uk.ibm.com says...
>
> All properties are included irrespective of property editors. The
> problem I think is because you are trying to have one property explicit
> and others implicit and this is not allowed - it is either all explicit
> or all implicit.
>
>
> Yes, and the VE is following the JavaBeans specification. Page 62 that
> describes the API for getPropertyDescriptors() states:
> "Returns: an array of PropertyDescriptors describing the editable
> properties supported by this bean. May return null if the information
> should be obtained by automatic analysis".
> Our reading of this is that null means "find automatically" and not null
> means "here they are". Once you provide your lineWeight you are saying
> "here they are" and we don't go and look for any more - you must provide
> the fully inclusive set.
OK, let me see if I can change your collective mind on this point. The
described behavior is actually not desired because:
First, maintenance: by modifying a single default beaninfo behavior, a
programmer is now (and for the future of the bean) required to support
explicit code for all other mutators that adds absolutely zero
additional knowledge to the software system.
Second, consistency: the spirit of the bean spec is for the tool to
provide reasonable defaults at all levels that can be *overridden* by
the beaninfo where non-default behavior is required. Even in VE, an
explicitly defined property descriptor is not required to specify a
property editor class: unless explicitly overridden, the type-specific
default editor is automatically provided. Adding a property descriptor
that defines a non-default beaninfo behavior for a single mutator does
not automatically invalidate the reasonableness of the property
descriptor defaults for all other mutators.
Third, authority: the bean spec is simply not a shining bastion of
authoritative knowledge and well considered design. Practical virtues
should not be overthrown merely on the basis of bad phrasing. The
sentence "May return null if the information should be obtained by
automatic analysis" is actually non-defining: it does not *preclude* the
true corollary "if the method returns non-null, other information may be
obtained by automatic analysis."
Also, the bean spec does explicitly provide for/require explicit
property desciptors to take precedence over introspected defaults. So,
the spirit if not well written letter of the spec intends beaninfos to
specify only *overrides* of default behavior.
Fourth, history: the visual editors and third-party beans/bean suites I
have encountered make the opposite presumption. For example, beaninfos
(vis. koders.com) that do not implement property descriptors for all
mutators do not have to override getAdditionalBeanInfo() to capture
their obviously missing properties. An override like this would be
necessary to get back the reasonable behavior:
/**
* Gets a BeanInfo for the <u> naked class </u> of this bean.
*
* @return BeanInfo[] containing this bean's native BeanInfo
*/
public BeanInfo[] getAdditionalBeanInfo() {
try {
BeanInfo[] bi = new BeanInfo[1];
bi[0] = Introspector.getBeanInfo(beanClass,
Introspector.IGNORE_IMMEDIATE_BEANINFO);
return bi;
} catch (IntrospectionException e) {
throw new Error(e.toString());
}
}
Consequently, the correct design choice is to change the behavior of VE
to automatically add default property descriptions for properties not
explicitly defined in a Beaninfo. Ultimately, it is a minor change to
VE, but one that I think will make VE better.
Of course, the above getAdditionalBeanInfo() routine is a workaround,
but only if the beaninfo source is available.
Should I add this as a bug/enhancement request to bugzilla?
> > 3) Is there something special I need to provide to enable use of a bean
> > customizer class?
> >
> Customizers should work - I just re-ran the test we have where we do
> various combinations of an AWT customizer and a Swing one and it worked
> OK. Looking at the code the action would be disabled if no customizer
> was returned, or the one returned couldn't be found. Is the customizer
> class that your BeanInfo returns maybe requiring stuff that isn't in the
> classpath ?
If I type the initial part of the customizer's name in the "Choose
Bean" dialog (as if it were a bean) it does show up in the list of
available beans in the correct package and sourced from the correct jar.
> Is there anything in the ErrorLog ?
!SESSION 2005-05-09 10:41:08.577
-----------------------------------------------
eclipse.buildId=I20050401-1645
java.version=1.5.0
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -DEBUG
file:/D:/DevFiles/Eclipse31M6/options.txt -data D:\DevFiles
\EclipseWorkSpace31M6
!ENTRY org.eclipse.jem.beaninfo 4 0 2005-05-09 10:50:39.509
!MESSAGE Exception thrown.
!STACK 0
java.lang.ClassNotFoundException: net.certiv.swing.GradientCustomizer
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass
(BundleLoader.java:361)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass
(BundleLoader.java:326)
at
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass
(AbstractClassLoader.java:74)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319 )
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass
(ObjectInputStream.java:574)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1538)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readClass
(ObjectInputStream.java:1427)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1282)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readArray
(ObjectInputStream.java:1628)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1293)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at
org.eclipse.jem.internal.beaninfo.adapters.BeanInfoDecorator Utility
$ProxyIntrospectCallBack.calledBackStream
(BeanInfoDecoratorUtility.java:357)
at org.eclipse.jem.internal.proxy.remote.REMCallbackThread.run
(REMCallbackThread.java:252)
> If not then open a
> bugzilla with as much details as you can including a repeatable test
> case and we'll take a look. If you are worried about posting source
> code to the bugzilla mention this on the bugzilla request and we'll find
> a way to get the source and test it.
Can you please post your known working Swing cusomizer example (or send
it to me at gbr XatX newtechlaw XdotX com). That would be considerably
more efficient than having me generate a known not working test case.
>
> Best regards,
>
> Joe Winchester
>
Thanks much!
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90268 is a reply to message #90253] |
Mon, 09 May 2005 19:41 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald,
> OK, let me see if I can change your collective mind on this point. The
> described behavior is actually not desired because:
>
> First, maintenance: by modifying a single default beaninfo behavior, a
> programmer is now (and for the future of the bean) required to support
> explicit code for all other mutators that adds absolutely zero
> additional knowledge to the software system.
There are circumstances when you want to have the behavior of all
explicit, for example if you subclass a Swing Container but don't want
the ability for the user to change the layout property, because although
it is a physical Container it is a logical Control. This is in fact
what javax.swing.Component is. If your wish to have the BeanInfo do
magic were being done this set of users would be complaining, so it's a
question of what is the principle of least astonishment. The JavaBeans
specification authors took the, in my opinion, right decision to make it
all explicit or all explicit. They also do state this in the JavaBeans
specification, the quote of which I used in the last post, and following
the spec is also important otherwise we'd get newsgroup posts from
people complaining about that.
What you want is sort of magic - the BeanInfo does something that is not
expected and, as any muggle knows, there's no such thing as magic :-)
If you want the behavior you want you could write your own BeanInfo that
looked at the properties on the JavaBean and looked at your explicit
list and sort of updated the explicit list with all of the ones you
figured out yourself weren't going to be there. That's my suggestion
and is just going the magic in your code rather than the VE code.
> Second, consistency: the spirit of the bean spec is for the tool to
> provide reasonable defaults at all levels that can be *overridden* by
> the beaninfo where non-default behavior is required. Even in VE, an
> explicitly defined property descriptor is not required to specify a
> property editor class: unless explicitly overridden, the type-specific
> default editor is automatically provided. Adding a property descriptor
> that defines a non-default beaninfo behavior for a single mutator does
> not automatically invalidate the reasonableness of the property
> descriptor defaults for all other mutators.
What you want invalidates the spec. Eclipse gets beaten up a ton for
not following specifications and it should be a last resort.
> Third, authority: the bean spec is simply not a shining bastion of
> authoritative knowledge and well considered design. Practical virtues
> should not be overthrown merely on the basis of bad phrasing. The
> sentence "May return null if the information should be obtained by
> automatic analysis" is actually non-defining: it does not *preclude* the
> true corollary "if the method returns non-null, other information may be
> obtained by automatic analysis."
I am not going to defend the spec, but we must do all we can to follow
it and being accused of not following a spec is worse than being accused
of doing magic. There is a JSR273 that has just been approved by the
JCP to update the JavaBeans specification and this topic should probably
be raised. By happy coincidence I will be representing IBM on this
expert group so I will bring the topic up, and if it can be shown that
all other tools providers ignore the spec and have sort of implemented
their own variant that has by popular opinion become the new standard
then I would push for the spec to be changed and we'd follow the change.
However we can't just ignore the spec.
> Also, the bean spec does explicitly provide for/require explicit
> property desciptors to take precedence over introspected defaults. So,
> the spirit if not well written letter of the spec intends beaninfos to
> specify only *overrides* of default behavior.
But the letter of the spec doesn't. A computer system can't follow the
spirit of something and not the letter - that's something objective
people can do but not the JVM unfortunately
> Fourth, history: the visual editors and third-party beans/bean suites I
> have encountered make the opposite presumption. For example, beaninfos
> (vis. koders.com) that do not implement property descriptors for all
> mutators do not have to override getAdditionalBeanInfo() to capture
> their obviously missing properties. An override like this would be
> necessary to get back the reasonable behavior:
Wow - I would have thought that three punches were enough to get your
point across. What other tools is a question you should ask of the
other tools.
You do not have to override getAdditionalBeanInfo() for missing
properties. This is for inherited properties.
All you need to do is make sure that the getPropertyDescriptors() method
returns a fully inclusive set. If you want it to include some that you
override and others you don't, then do something like get the set you
want explicit, use reflection to work out the missing ones, and return
these as the set.
> /**
> * Gets a BeanInfo for the <u> naked class </u> of this bean.
> *
> * @return BeanInfo[] containing this bean's native BeanInfo
> */
> public BeanInfo[] getAdditionalBeanInfo() {
> try {
> BeanInfo[] bi = new BeanInfo[1];
> bi[0] = Introspector.getBeanInfo(beanClass,
> Introspector.IGNORE_IMMEDIATE_BEANINFO);
> return bi;
> } catch (IntrospectionException e) {
> throw new Error(e.toString());
> }
> }
>
> Consequently, the correct design choice is to change the behavior of VE
> to automatically add default property descriptions for properties not
> explicitly defined in a Beaninfo. Ultimately, it is a minor change to
> VE, but one that I think will make VE better.
I follow your argument, but not your conclusion.
> Of course, the above getAdditionalBeanInfo() routine is a workaround,
> but only if the beaninfo source is available.
>
> Should I add this as a bug/enhancement request to bugzilla?
Absolutely and we can discuss this further and have it voted on.
Thanks for your arguments and great input - what happened to your
customizer - did you get that working ?
Joe Winchester
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90283 is a reply to message #90268] |
Tue, 10 May 2005 00:01 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
Joe,
Thanks for the response. Let me try and sum it up:
Your (the royal you) position is:
1) the spec is clear and you have to follow it
2) cannot do magic
3) must be always mindfull of the principle of least astonishment.
4) what happened to my customizer problem?
My rejoinder is:
1) the spec on point is not clear, certainly not in the King's English
and (watch the toes, apologies in advance) anyone who contends
differently must have an external agenda. There is just nothing in the
language of the spec *itself* that supports the very narrow reading
proposed. And, yes, I am a lawyer (also an EE) quite versed in specs
and licenses. So, if anyone gives you grief on this point, please feel
free to direct them my way for clarification: you cannot get blood from
a stone and if the spec is not objectively clear, you must interpret
(apologies to Johnny), meaning principled analysis of the spirit of the
spec by analogy to related concepts/requirements/constructs and attempt
to remain consistent in the implemented behaviours.
2) the fundamental nature of the Introspector is *magic*, at least if
magic is defined as automatically providing reasonable defaults to
intensionally minimize the work of the programmer and the risk of bugs
in the program (of course, all according to the plan of the Architect
program).
3) for the container example you provided, the construct
public BeanInfo[] getAdditionalBeanInfo() {
return null;
}
is actually quite common in the beaninfos that I have seen. Conversely,
I have yet to find an where anyone has needed or chosen to use the code
presented in my prior post. While the principle of least astonishment
is proper for guidance, no one can just presume to know what others
expect.
Now, I do not presume to know what you (the royal you) know, but my
experience is that my beans work correctly in Jigloo, JDeveloper 9 and
10, JBuilder 7, (a couple I cannot remember at the moment), and Visual
Cafe 4.1. Only now, and only for VE, I am having to patch the beaninfos
to force the visibility of default properties. My well-founded
astonishment is that VE is the odd man out on this point.
Anyway, thats probably enough on this topic. I am glad to hear that you
are on the relevant committees and hope you will support the best
technical (not semantic) argument for most beneficial beaninfo behavior.
If I can be of assistance in that endeavor, please let me know how I can
help.
4) additional information regarding my customizer problem was provided
at the end of my last post. While it shows up in my newsreader, if it
is not visible to you, I could repeat it into a separate thread.
Further, I found the separate VE examples download and will try to get
the ButtonBar customizer sample to work - or were you referring to a
differnt/better Swing example used to confirm customizer operation?
Thanks,
Gerald
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90385 is a reply to message #90283] |
Tue, 10 May 2005 09:38 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Gerald Rosenberg wrote:
> Now, I do not presume to know what you (the royal you) know, but my
> experience is that my beans work correctly in Jigloo, JDeveloper 9 and
> 10, JBuilder 7, (a couple I cannot remember at the moment), and Visual
> Cafe 4.1. Only now, and only for VE, I am having to patch the beaninfos
> to force the visibility of default properties. My well-founded
> astonishment is that VE is the odd man out on this point.
For various reasons that I am sure you appreicate it is hard for us to
look directly at other tools, however we do not wish to be inconsistent
and I do take all your arguments as valid.
I have e-mailed the Sun engineer who looks after the JavaBeans
specification to ask for their clarification on this position and I will
try to get a discusson on this as soon as possible on JSR273 JavaBeans
expert group. We will do whatever the spec says, and if the spec has to
be amended to follow what is de-facto implementation then we will
support the change and follow the new amendment.
> Anyway, thats probably enough on this topic. I am glad to hear that you
> are on the relevant committees and hope you will support the best
> technical (not semantic) argument for most beneficial beaninfo behavior.
> If I can be of assistance in that endeavor, please let me know how I can
> help.
This would be great. If you could please write up a document that
describes the behavior you see with various tools and point out how this
is inconsistent with the spec that would be great. Try to go easy on
the emotional arguments and make it very matter of fact. You can either
post this to the newsgroup or just e-mail it to me directly.
> 4) additional information regarding my customizer problem was provided
> at the end of my last post. While it shows up in my newsreader, if it
> is not visible to you, I could repeat it into a separate thread.
Glad you fixed it - I am curious what the problem was. Is it something
we could improve in the VE editor >
> Further, I found the separate VE examples download and will try to get
> the ButtonBar customizer sample to work - or were you referring to a
> differnt/better Swing example used to confirm customizer operation?
Our examples plugin is sort of in flux - the one I actually used was
Area in our org.eclipse.ve.examples.
Best regards,
Joe
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90530 is a reply to message #90385] |
Tue, 10 May 2005 17:24 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d5pvt7$jcn$1@news.eclipse.org>, winchest@uk.ibm.com says...
> Gerald Rosenberg wrote:
>
> > Anyway, thats probably enough on this topic. I am glad to hear that you
> > are on the relevant committees and hope you will support the best
> > technical (not semantic) argument for most beneficial beaninfo behavior.
> > If I can be of assistance in that endeavor, please let me know how I can
> > help.
>
> This would be great. If you could please write up a document that
> describes the behavior you see with various tools and point out how this
> is inconsistent with the spec that would be great. Try to go easy on
> the emotional arguments and make it very matter of fact. You can either
> post this to the newsgroup or just e-mail it to me directly.
>
> > 4) additional information regarding my customizer problem was provided
> > at the end of my last post. While it shows up in my newsreader, if it
> > is not visible to you, I could repeat it into a separate thread.
>
> Glad you fixed it - I am curious what the problem was. Is it something
> we could improve in the VE editor >
>
Looks like two changes are needed.
1) VE throws a class not found error if the BeanDescriptor returned by
getBeanDescriptor() includes a FeatureDescriptor key and value of
"customizerClass" and the customizer class.
Specifically, this works:
public BeanDescriptor getBeanDescriptor1() {
BeanDescriptor result = new BeanDescriptor(
JStatusBar.class, ColorCustomizer.class);
return result;
}
This does not:
public BeanDescriptor getBeanDescriptor1() {
BeanDescriptor result = new BeanDescriptor(
JStatusBar.class, ColorCustomizer.class);
result.setValue("customizerClass", ColorCustomizer.class);
return result;
}
Obviously, adding the customizer to the FeatureDescriptor is not
necessary, but it is what is done by default by Sun's own SwingBeanInfo
class (the one in Sun's dt.jar through 1.4.x). See,
SwingBeanInfo#createBeanDescriptor(Class cls, Object[] args).
2) Seems that VE is calling getDefaultPropertyIndex() on all properties,
not just indexed properties. If anything other than -1 is returned for
a non-indexed property, I get a fatal null pointer exception from the
remote VM (below). VE needs to be more selective in when it calls
getDefaultPropertyIndex().
Regards,
Gerald
!ENTRY org.eclipse.jem.beaninfo 2 0 2005-05-10 10:07:01.551
!MESSAGE IWAV0155E Introspection failed on class
"net.certiv.swing.JStatusBar." msg="."
!STACK 0
IWAV0073I *** RemoteVM Exception - Trace from Remote VM:
java.lang.NullPointerException
at java.beans.Introspector.getTargetPropertyInfo
(Introspector.java:477)
at java.beans.Introspector.getBeanInfo(Introspector.java:385)
at java.beans.Introspector.getBeanInfo(Introspector.java:155)
at
org.eclipse.jem.internal.beaninfo.vm.ModelingBeanInfo.intros pect
(ModelingBeanInfo.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.jem.internal.proxy.vm.remote.ConnectionHandler.r un
(ConnectionHandler.java:316)
at org.eclipse.jem.internal.proxy.vm.remote.ConnectionThread.ru n
(ConnectionThread.java:47)
IWAV0074I *** Local StackTrace:
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanProxyP roxy:
java.lang.NullPointerException
at
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.createTh
rowableBeanProxy(REMThrowableBeanTypeProxy.java:34)
at
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.newBeanP
roxy(REMThrowableBeanTypeProxy.java:65)
at
org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.getBea
nProxy(REMStandardBeanProxyFactory.java:454)
at
org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.proces
sErrorReturn(REMStandardBeanProxyFactory.java:505)
at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
(REMMethodProxy.java:216)
at
org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invokeW ithParms
(REMMethodProxy.java:175)
at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
(REMMethodProxy.java:101)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ct(BeaninfoClassAdapter.java:756)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ctIfNecessary(BeaninfoClassAdapter.java:472)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ctIfNecessary(BeaninfoClassAdapter.java:459)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.getEStru
cturalFeatures(BeaninfoClassAdapter.java:1070)
at org.eclipse.jem.java.impl.JavaClassImpl.getEStructuralFeatur es
(JavaClassImpl.java:382)
at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributesGen
(EClassImpl.java:204)
at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributes
(EClassImpl.java:242)
at org.eclipse.emf.ecore.impl.EClassImpl.getEIDAttribute
(EClassImpl.java:136)
at org.eclipse.emf.ecore.util.EcoreUtil.getID(EcoreUtil.java:24 80)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragm ent
(ResourceImpl.java:529)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.getURIFragmen t
(XMLResourceImpl.java:355)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getURIFragment
(XMLHelperImpl.java:617)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getIDREF
(XMLHelperImpl.java:631)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveIDRefSingle
(XMLSaveImpl.java:1602)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
(XMLSaveImpl.java:1015)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
(XMLSaveImpl.java:2214)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement
(XMLSaveImpl.java:885)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany
(XMLSaveImpl.java:1943)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
(XMLSaveImpl.java:1208)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
(XMLSaveImpl.java:2214)
at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects
(XMISaveImpl.java:76)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse
(XMLSaveImpl.java:474)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save
(XMLSaveImpl.java:204)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave
(XMLResourceImpl.java:192)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
(ResourceImpl.java:893)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
(ResourceImpl.java:813)
at
org.eclipse.ve.internal.java.codegen.util.VEModelCacheUtilit y.doSaveCach
e(VEModelCacheUtility.java:154)
at
org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslat or.doSave
(JavaSourceTranslator.java:1368)
at
org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart.doS
ave(JavaVisualEditorPart.java:2498)
at org.eclipse.ui.internal.EditorManager$8.run
(EditorManager.java:1386)
at org.eclipse.ui.internal.SaveableHelper$2.run
(SaveableHelper.java:116)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread
(ModalContext.java:346)
at org.eclipse.jface.operation.ModalContext.run
(ModalContext.java:291)
at org.eclipse.jface.window.ApplicationWindow$1.run
(ApplicationWindow.java:624)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.jface.window.ApplicationWindow.run
(ApplicationWindow.java:621)
at org.eclipse.ui.internal.WorkbenchWindow.run
(WorkbenchWindow.java:1975)
at
org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOpe ration
(SaveableHelper.java:122)
at org.eclipse.ui.internal.EditorManager.saveAll
(EditorManager.java:1406)
at org.eclipse.ui.internal.Workbench$11.run(Workbench.java:579)
at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:1021)
at org.eclipse.core.runtime.Platform.run(Platform.java:757)
at org.eclipse.ui.internal.Workbench.saveAllEditors
(Workbench.java:550)
at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:4 70)
at org.eclipse.ui.internal.Workbench.access$6(Workbench.java:46 1)
at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:645)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:643)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:618)
at org.eclipse.ui.internal.WorkbenchWindow.busyClose
(WorkbenchWindow.java:536)
at org.eclipse.ui.internal.WorkbenchWindow.access$0
(WorkbenchWindow.java:520)
at org.eclipse.ui.internal.WorkbenchWindow$1.run
(WorkbenchWindow.java:621)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.ui.internal.WorkbenchWindow.close
(WorkbenchWindow.java:619)
at org.eclipse.jface.window.Window.handleShellCloseEvent
(Window.java:721)
at org.eclipse.jface.window.Window$3.shellClosed(Window.java:66 8)
at org.eclipse.swt.widgets.TypedListener.handleEvent
(TypedListener.java:158)
at org.eclipse.swt.widgets.EventTable.sendEvent
(EventTable.java:82)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851)
at org.eclipse.swt.widgets.Decorations.closeWidget
(Decorations.java:256)
at org.eclipse.swt.widgets.Decorations.WM_CLOSE
(Decorations.java:1568)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3031 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native
Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 25)
at org.eclipse.swt.widgets.Display.readAndDispatch
(Display.java:2525)
at org.eclipse.ui.internal.Workbench.runEventLoop
(Workbench.java:1570)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1534)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench
(Workbench.java:306)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench
(PlatformUI.java:143)
at org.eclipse.ui.internal.ide.IDEApplication.run
(IDEApplication.java:103)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run
(PlatformActivator.java:228)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:315 )
at org.eclipse.core.launcher.Main.basicRun(Main.java:268)
at org.eclipse.core.launcher.Main.run(Main.java:942)
at org.eclipse.core.launcher.Main.main(Main.java:926)
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90545 is a reply to message #90530] |
Tue, 10 May 2005 18:55 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Thanks for the info but we need a little more info please:
For the following, please tell me what JDK, and VE are you using. We
never look at "customizerClass" attributes. Is there a log trace where
you get this classNotFound message. That would be helpful. Then we can
trace why you get this and fix it.
>
> Looks like two changes are needed.
>
> 1) VE throws a class not found error if the BeanDescriptor returned by
> getBeanDescriptor() includes a FeatureDescriptor key and value of
> "customizerClass" and the customizer class.
>
> Specifically, this works:
>
> public BeanDescriptor getBeanDescriptor1() {
> BeanDescriptor result = new BeanDescriptor(
> JStatusBar.class, ColorCustomizer.class);
> return result;
> }
>
> This does not:
>
> public BeanDescriptor getBeanDescriptor1() {
> BeanDescriptor result = new BeanDescriptor(
> JStatusBar.class, ColorCustomizer.class);
> result.setValue("customizerClass", ColorCustomizer.class);
> return result;
> }
>
> Obviously, adding the customizer to the FeatureDescriptor is not
> necessary, but it is what is done by default by Sun's own SwingBeanInfo
> class (the one in Sun's dt.jar through 1.4.x). See,
> SwingBeanInfo#createBeanDescriptor(Class cls, Object[] args).
>
For the following, default property index has nothing to do with indexed
properties. The index returned is the index of the property within the
array of properties returned for this bean that is the default property.
It is not called on any properties, it is a method on the BeanInfo
class, so it is called only once. So the number returned (if not -1)
must be within the range of 0 to one less than the size of the array of
properties for the bean. This is a java.beans.BeanDescriptor
requirement, not a VE requirement.
Here is the comment for the code directly out of the JDK:
/**
* A bean may have a "default" property that is the property that will
* mostly commonly be initially chosen for update by human's who are
* customizing the bean.
* @return Index of default property in the PropertyDescriptor array
* returned by getPropertyDescriptors.
* <P> Returns -1 if there is no default property.
*/
Unfortunately your Introspector class (which is from the JDK) is
different than mine so the line numbers don't match up. From looking at
the Java Introspector code, the only way I could think of that returning
something other than -1 is if the BeanInfo that is returning the index
IS NOT returning an array from the getProperties() call. The index
returned is supposed to be within the range of the properties from the
getProperties() method on the BeanInfo. This is invalid.
> 2) Seems that VE is calling getDefaultPropertyIndex() on all properties,
> not just indexed properties. If anything other than -1 is returned for
> a non-indexed property, I get a fatal null pointer exception from the
> remote VM (below). VE needs to be more selective in when it calls
> getDefaultPropertyIndex().
>
> Regards,
> Gerald
>
>
>
>
> !ENTRY org.eclipse.jem.beaninfo 2 0 2005-05-10 10:07:01.551
> !MESSAGE IWAV0155E Introspection failed on class
> "net.certiv.swing.JStatusBar." msg="."
> !STACK 0
> IWAV0073I *** RemoteVM Exception - Trace from Remote VM:
> java.lang.NullPointerException
> at java.beans.Introspector.getTargetPropertyInfo
> (Introspector.java:477)
> at java.beans.Introspector.getBeanInfo(Introspector.java:385)
> at java.beans.Introspector.getBeanInfo(Introspector.java:155)
> at
> org.eclipse.jem.internal.beaninfo.vm.ModelingBeanInfo.intros pect
> (ModelingBeanInfo.java:182)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jem.internal.proxy.vm.remote.ConnectionHandler.r un
> (ConnectionHandler.java:316)
> at org.eclipse.jem.internal.proxy.vm.remote.ConnectionThread.ru n
> (ConnectionThread.java:47)
> IWAV0074I *** Local StackTrace:
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanProxyP roxy:
> java.lang.NullPointerException
> at
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.createTh
> rowableBeanProxy(REMThrowableBeanTypeProxy.java:34)
> at
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.newBeanP
> roxy(REMThrowableBeanTypeProxy.java:65)
> at
> org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.getBea
> nProxy(REMStandardBeanProxyFactory.java:454)
> at
> org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.proces
> sErrorReturn(REMStandardBeanProxyFactory.java:505)
> at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
> (REMMethodProxy.java:216)
> at
> org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invokeW ithParms
> (REMMethodProxy.java:175)
> at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
> (REMMethodProxy.java:101)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ct(BeaninfoClassAdapter.java:756)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ctIfNecessary(BeaninfoClassAdapter.java:472)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ctIfNecessary(BeaninfoClassAdapter.java:459)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.getEStru
> cturalFeatures(BeaninfoClassAdapter.java:1070)
> at org.eclipse.jem.java.impl.JavaClassImpl.getEStructuralFeatur es
> (JavaClassImpl.java:382)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributesGen
> (EClassImpl.java:204)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributes
> (EClassImpl.java:242)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEIDAttribute
> (EClassImpl.java:136)
> at org.eclipse.emf.ecore.util.EcoreUtil.getID(EcoreUtil.java:24 80)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragm ent
> (ResourceImpl.java:529)
> at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.getURIFragmen t
> (XMLResourceImpl.java:355)
> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getURIFragment
> (XMLHelperImpl.java:617)
> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getIDREF
> (XMLHelperImpl.java:631)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveIDRefSingle
> (XMLSaveImpl.java:1602)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
> (XMLSaveImpl.java:1015)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
> (XMLSaveImpl.java:2214)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement
> (XMLSaveImpl.java:885)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany
> (XMLSaveImpl.java:1943)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
> (XMLSaveImpl.java:1208)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
> (XMLSaveImpl.java:2214)
> at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects
> (XMISaveImpl.java:76)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse
> (XMLSaveImpl.java:474)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save
> (XMLSaveImpl.java:204)
> at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave
> (XMLResourceImpl.java:192)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
> (ResourceImpl.java:893)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
> (ResourceImpl.java:813)
> at
> org.eclipse.ve.internal.java.codegen.util.VEModelCacheUtilit y.doSaveCach
> e(VEModelCacheUtility.java:154)
> at
> org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslat or.doSave
> (JavaSourceTranslator.java:1368)
> at
> org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart.doS
> ave(JavaVisualEditorPart.java:2498)
> at org.eclipse.ui.internal.EditorManager$8.run
> (EditorManager.java:1386)
> at org.eclipse.ui.internal.SaveableHelper$2.run
> (SaveableHelper.java:116)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread
> (ModalContext.java:346)
> at org.eclipse.jface.operation.ModalContext.run
> (ModalContext.java:291)
> at org.eclipse.jface.window.ApplicationWindow$1.run
> (ApplicationWindow.java:624)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.jface.window.ApplicationWindow.run
> (ApplicationWindow.java:621)
> at org.eclipse.ui.internal.WorkbenchWindow.run
> (WorkbenchWindow.java:1975)
> at
> org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOpe ration
> (SaveableHelper.java:122)
> at org.eclipse.ui.internal.EditorManager.saveAll
> (EditorManager.java:1406)
> at org.eclipse.ui.internal.Workbench$11.run(Workbench.java:579)
> at org.eclipse.core.internal.runtime.InternalPlatform.run
> (InternalPlatform.java:1021)
> at org.eclipse.core.runtime.Platform.run(Platform.java:757)
> at org.eclipse.ui.internal.Workbench.saveAllEditors
> (Workbench.java:550)
> at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:4 70)
> at org.eclipse.ui.internal.Workbench.access$6(Workbench.java:46 1)
> at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:645)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.ui.internal.Workbench.close(Workbench.java:643)
> at org.eclipse.ui.internal.Workbench.close(Workbench.java:618)
> at org.eclipse.ui.internal.WorkbenchWindow.busyClose
> (WorkbenchWindow.java:536)
> at org.eclipse.ui.internal.WorkbenchWindow.access$0
> (WorkbenchWindow.java:520)
> at org.eclipse.ui.internal.WorkbenchWindow$1.run
> (WorkbenchWindow.java:621)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.ui.internal.WorkbenchWindow.close
> (WorkbenchWindow.java:619)
> at org.eclipse.jface.window.Window.handleShellCloseEvent
> (Window.java:721)
> at org.eclipse.jface.window.Window$3.shellClosed(Window.java:66 8)
> at org.eclipse.swt.widgets.TypedListener.handleEvent
> (TypedListener.java:158)
> at org.eclipse.swt.widgets.EventTable.sendEvent
> (EventTable.java:82)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851)
> at org.eclipse.swt.widgets.Decorations.closeWidget
> (Decorations.java:256)
> at org.eclipse.swt.widgets.Decorations.WM_CLOSE
> (Decorations.java:1568)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3031 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
> at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
> at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native
> Method)
> at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 25)
> at org.eclipse.swt.widgets.Display.readAndDispatch
> (Display.java:2525)
> at org.eclipse.ui.internal.Workbench.runEventLoop
> (Workbench.java:1570)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1534)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench
> (Workbench.java:306)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench
> (PlatformUI.java:143)
> at org.eclipse.ui.internal.ide.IDEApplication.run
> (IDEApplication.java:103)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run
> (PlatformActivator.java:228)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run
> (EclipseStarter.java:344)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run
> (EclipseStarter.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:315 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:268)
> at org.eclipse.core.launcher.Main.run(Main.java:942)
> at org.eclipse.core.launcher.Main.main(Main.java:926)
--
Thanks,
Rich Kulp
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90559 is a reply to message #90545] |
Tue, 10 May 2005 21:49 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d5r0ih$1df$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> Thanks for the info but we need a little more info please:
>
> For the following, please tell me what JDK, and VE are you using. We
> never look at "customizerClass" attributes. Is there a log trace where
> you get this classNotFound message. That would be helpful. Then we can
> trace why you get this and fix it.
>
JDK1.5
Eclipse 3.1M6
EMF build I200504141117
GEF Build 3.1M6
VE-runtime-1.1M1
You should be able to reproduce the error from the code provided in the
prior post - just add the one line to the AreaBeanInfo. I will get you
a stack trace from my system shortly.
FWIW, my guess is that whatever code is evaluating the feature
descriptor is recognizing the customizer class, if not by key then as a
class object, and tries to load it, resulting in the not found error.
> Unfortunately your Introspector class (which is from the JDK) is
> different than mine so the line numbers don't match up. From looking at
> the Java Introspector code, the only way I could think of that returning
> something other than -1 is if the BeanInfo that is returning the index
> IS NOT returning an array from the getProperties() call.
I will recheck my code. To be sure, Sun's SwingBeanInfo overrides
getDefaultPropertyIndex() to *always* return 0. My beaninfos extend
SwingBeanInfo but do not further override getDefaultPropertyIndex().
Commenting out getDefaultPropertyIndex() in SwingBeanInfo - exposing
getDefaultPropertyIndex() in SimpleBeanInfo - removes the error.
I have been using Sun's SwingBeanInfo simply because that is what Sun's
own beaninfos use (or used). As of 1.5, it seems that Sun has switched
to SwingBeanInfoBase (http://java.sun.com/j2se/1.5.0/jcp/beta2/).
Two notable details: logging shows that SwingBeanInfoBase still loads
the feature descriptor with the customizer class and still overrides
getDefaultPropertyIndex() to always return a value of 0.
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90576 is a reply to message #90559] |
Tue, 10 May 2005 22:51 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
As for the customizer problem, I think I know what's wrong. Please open
a Bugzilla against VE project, Java Model (JEM) component so that we can
fix it and track it.
For the default property index, my presumption is that they expect only
javax.swing classes to use SwingBeanInfo, and nobody else. The
specification for SwingBeanInfoBase specifies that it is only for
javax.swing classes. And I guess all Swing BeanInfo's will return
something from getPropertyDescriptors() AND the first descriptor will be
the default property.
The spec from the link in the append indicates:
>> However, products that ship BeanInfos in the javax.swing namespace
>> and that are based on or targeted for J2SE 1.6 will be required to
>> conform to the Swing BeanInfo optional package specification.
This implies that if not for javax.swing, then it should not be used.
--
Thanks,
Rich Kulp
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90590 is a reply to message #90576] |
Wed, 11 May 2005 03:48 |
| Eclipse User |
|
|
|
Originally posted by: no.ddress.here
In article <d5red0$h1e$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> As for the customizer problem, I think I know what's wrong. Please open
> a Bugzilla against VE project, Java Model (JEM) component so that we can
> fix it and track it.
Bug 94587
> For the default property index, my presumption is that they expect only
> javax.swing classes to use SwingBeanInfo, and nobody else. The
> specification for SwingBeanInfoBase specifies that it is only for
> javax.swing classes. And I guess all Swing BeanInfo's will return
> something from getPropertyDescriptors() AND the first descriptor will be
> the default property.
>
> The spec from the link in the append indicates:
>
> >> However, products that ship BeanInfos in the javax.swing namespace
> >> and that are based on or targeted for J2SE 1.6 will be required to
> >> conform to the Swing BeanInfo optional package specification.
>
> This implies that if not for javax.swing, then it should not be used.
Well, I would agree that Sun does not make it particularly easy to use
given the nearly hidden source and dearth of documentation.
So, from your suggestion not to use the Sun classes, what is a better
helper class to use - writing directly to SimpleBeanInfo is just plain
clumsy and error prone. What convenience class do you use or recommend?
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #90618 is a reply to message #90590] |
Wed, 11 May 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
We actually wrote our own. You can copy it and use it if you wish.
Unless you will only be running your BeanInfo within the VE environment,
I don't recommend using our class directly. Because it would not be
available outside of VE environment unless you copy the one class. It is
Opensource, so you can copy it if you follow the Eclipse license just
for that class.
It is called BaseBeanInfo and is in the org.eclipse.jem.beaninfo plugin.
You can get the source either from Eclipse CVS directly or from the
source jar inside
org.eclipse.jem.sdk/src/org.eclipse.jem.beaninfo/vm/beaninfo src.zip.
--
Thanks,
Rich Kulp
|
|
| |
| Re: Clarifications on using BeanInfo customizers? [message #607369 is a reply to message #90133] |
Mon, 09 May 2005 10:02 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald Rosenber,
> 2) if my BeanInfo contains custom property editors, seems that VE does
> not introspect the bean for properties that do not have customizers.
All properties are included irrespective of property editors. The
problem I think is because you are trying to have one property explicit
and others implicit and this is not allowed - it is either all explicit
or all implicit.
> For example, my bean (an extension of JLabel) specifies a property
> editor for get/setLineWeight and that does show up in VE's property
> sheet along with the standard JLabel properties. My bean also has
> standard named is/setLineEnabled methods. Since there is no need for a
> lineEnabled property editor class, the lineEnabled property is not
> explicitly defined in the beaninfo. While other visual editors - Jigloo
> specifically - automatically find and show both properties, using a
> default boolean editor for lineEnabled, the lineEnabled property does
> not show up in the VE property sheet.
> Is this expected behavior for VE?
Yes, and the VE is following the JavaBeans specification. Page 62 that
describes the API for getPropertyDescriptors() states:
"Returns: an array of PropertyDescriptors describing the editable
properties supported by this bean. May return null if the information
should be obtained by automatic analysis".
Our reading of this is that null means "find automatically" and not null
means "here they are". Once you provide your lineWeight you are saying
"here they are" and we don't go and look for any more - you must provide
the fully inclusive set.
> Must I list all custom properties if
> any one has a custom editor? Or is VE looking for something in the
> beaninfo to key it to also introspect the bean?
The properties must all be there. You don't need to provide a custom
editor for your lineEnabled property as it is boolean so the VE will use
the correct editor for booleans, so you just return an array with
them all there that you want to see. If there are any inherited ones
you want to see this is done with the getAdditionalBeanInfo().
> 3) Is there something special I need to provide to enable use of a bean
> customizer class?
>
> In other visual editors, such as Jigloo, a double click on the bean in
> the design editor will start the customizer class. In VE, double
> clicking only lets me change the label text. The toolbar button
> "Customize Java Bean" seems permanently disabled.
Customizers should work - I just re-ran the test we have where we do
various combinations of an AWT customizer and a Swing one and it worked
OK. Looking at the code the action would be disabled if no customizer
was returned, or the one returned couldn't be found. Is the customizer
class that your BeanInfo returns maybe requiring stuff that isn't in the
classpath ? Is there anything in the ErrorLog ? If not then open a
bugzilla with as much details as you can including a repeatable test
case and we'll take a look. If you are worried about posting source
code to the bugzilla mention this on the bugzilla request and we'll find
a way to get the source and test it.
Best regards,
Joe Winchester
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607373 is a reply to message #90194] |
Mon, 09 May 2005 18:14 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
In article <d5ncuf$gf6$1@news.eclipse.org>, winchest@uk.ibm.com says...
>
> All properties are included irrespective of property editors. The
> problem I think is because you are trying to have one property explicit
> and others implicit and this is not allowed - it is either all explicit
> or all implicit.
>
>
> Yes, and the VE is following the JavaBeans specification. Page 62 that
> describes the API for getPropertyDescriptors() states:
> "Returns: an array of PropertyDescriptors describing the editable
> properties supported by this bean. May return null if the information
> should be obtained by automatic analysis".
> Our reading of this is that null means "find automatically" and not null
> means "here they are". Once you provide your lineWeight you are saying
> "here they are" and we don't go and look for any more - you must provide
> the fully inclusive set.
OK, let me see if I can change your collective mind on this point. The
described behavior is actually not desired because:
First, maintenance: by modifying a single default beaninfo behavior, a
programmer is now (and for the future of the bean) required to support
explicit code for all other mutators that adds absolutely zero
additional knowledge to the software system.
Second, consistency: the spirit of the bean spec is for the tool to
provide reasonable defaults at all levels that can be *overridden* by
the beaninfo where non-default behavior is required. Even in VE, an
explicitly defined property descriptor is not required to specify a
property editor class: unless explicitly overridden, the type-specific
default editor is automatically provided. Adding a property descriptor
that defines a non-default beaninfo behavior for a single mutator does
not automatically invalidate the reasonableness of the property
descriptor defaults for all other mutators.
Third, authority: the bean spec is simply not a shining bastion of
authoritative knowledge and well considered design. Practical virtues
should not be overthrown merely on the basis of bad phrasing. The
sentence "May return null if the information should be obtained by
automatic analysis" is actually non-defining: it does not *preclude* the
true corollary "if the method returns non-null, other information may be
obtained by automatic analysis."
Also, the bean spec does explicitly provide for/require explicit
property desciptors to take precedence over introspected defaults. So,
the spirit if not well written letter of the spec intends beaninfos to
specify only *overrides* of default behavior.
Fourth, history: the visual editors and third-party beans/bean suites I
have encountered make the opposite presumption. For example, beaninfos
(vis. koders.com) that do not implement property descriptors for all
mutators do not have to override getAdditionalBeanInfo() to capture
their obviously missing properties. An override like this would be
necessary to get back the reasonable behavior:
/**
* Gets a BeanInfo for the <u> naked class </u> of this bean.
*
* @return BeanInfo[] containing this bean's native BeanInfo
*/
public BeanInfo[] getAdditionalBeanInfo() {
try {
BeanInfo[] bi = new BeanInfo[1];
bi[0] = Introspector.getBeanInfo(beanClass,
Introspector.IGNORE_IMMEDIATE_BEANINFO);
return bi;
} catch (IntrospectionException e) {
throw new Error(e.toString());
}
}
Consequently, the correct design choice is to change the behavior of VE
to automatically add default property descriptions for properties not
explicitly defined in a Beaninfo. Ultimately, it is a minor change to
VE, but one that I think will make VE better.
Of course, the above getAdditionalBeanInfo() routine is a workaround,
but only if the beaninfo source is available.
Should I add this as a bug/enhancement request to bugzilla?
> > 3) Is there something special I need to provide to enable use of a bean
> > customizer class?
> >
> Customizers should work - I just re-ran the test we have where we do
> various combinations of an AWT customizer and a Swing one and it worked
> OK. Looking at the code the action would be disabled if no customizer
> was returned, or the one returned couldn't be found. Is the customizer
> class that your BeanInfo returns maybe requiring stuff that isn't in the
> classpath ?
If I type the initial part of the customizer's name in the "Choose
Bean" dialog (as if it were a bean) it does show up in the list of
available beans in the correct package and sourced from the correct jar.
> Is there anything in the ErrorLog ?
!SESSION 2005-05-09 10:41:08.577
-----------------------------------------------
eclipse.buildId=I20050401-1645
java.version=1.5.0
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -DEBUG
file:/D:/DevFiles/Eclipse31M6/options.txt -data D:\DevFiles
\EclipseWorkSpace31M6
!ENTRY org.eclipse.jem.beaninfo 4 0 2005-05-09 10:50:39.509
!MESSAGE Exception thrown.
!STACK 0
java.lang.ClassNotFoundException: net.certiv.swing.GradientCustomizer
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass
(BundleLoader.java:361)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findCl ass
(BundleLoader.java:326)
at
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader. loadClass
(AbstractClassLoader.java:74)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319 )
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass
(ObjectInputStream.java:574)
at java.io.ObjectInputStream.readNonProxyDesc
(ObjectInputStream.java:1538)
at java.io.ObjectInputStream.readClassDesc
(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readClass
(ObjectInputStream.java:1427)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1282)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readArray
(ObjectInputStream.java:1628)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1293)
at java.io.ObjectInputStream.defaultReadFields
(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData
(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject
(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0
(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:339)
at
org.eclipse.jem.internal.beaninfo.adapters.BeanInfoDecorator Utility
$ProxyIntrospectCallBack.calledBackStream
(BeanInfoDecoratorUtility.java:357)
at org.eclipse.jem.internal.proxy.remote.REMCallbackThread.run
(REMCallbackThread.java:252)
> If not then open a
> bugzilla with as much details as you can including a repeatable test
> case and we'll take a look. If you are worried about posting source
> code to the bugzilla mention this on the bugzilla request and we'll find
> a way to get the source and test it.
Can you please post your known working Swing cusomizer example (or send
it to me at gbr XatX newtechlaw XdotX com). That would be considerably
more efficient than having me generate a known not working test case.
>
> Best regards,
>
> Joe Winchester
>
Thanks much!
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607374 is a reply to message #90253] |
Mon, 09 May 2005 19:41 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Hi Gerald,
> OK, let me see if I can change your collective mind on this point. The
> described behavior is actually not desired because:
>
> First, maintenance: by modifying a single default beaninfo behavior, a
> programmer is now (and for the future of the bean) required to support
> explicit code for all other mutators that adds absolutely zero
> additional knowledge to the software system.
There are circumstances when you want to have the behavior of all
explicit, for example if you subclass a Swing Container but don't want
the ability for the user to change the layout property, because although
it is a physical Container it is a logical Control. This is in fact
what javax.swing.Component is. If your wish to have the BeanInfo do
magic were being done this set of users would be complaining, so it's a
question of what is the principle of least astonishment. The JavaBeans
specification authors took the, in my opinion, right decision to make it
all explicit or all explicit. They also do state this in the JavaBeans
specification, the quote of which I used in the last post, and following
the spec is also important otherwise we'd get newsgroup posts from
people complaining about that.
What you want is sort of magic - the BeanInfo does something that is not
expected and, as any muggle knows, there's no such thing as magic :-)
If you want the behavior you want you could write your own BeanInfo that
looked at the properties on the JavaBean and looked at your explicit
list and sort of updated the explicit list with all of the ones you
figured out yourself weren't going to be there. That's my suggestion
and is just going the magic in your code rather than the VE code.
> Second, consistency: the spirit of the bean spec is for the tool to
> provide reasonable defaults at all levels that can be *overridden* by
> the beaninfo where non-default behavior is required. Even in VE, an
> explicitly defined property descriptor is not required to specify a
> property editor class: unless explicitly overridden, the type-specific
> default editor is automatically provided. Adding a property descriptor
> that defines a non-default beaninfo behavior for a single mutator does
> not automatically invalidate the reasonableness of the property
> descriptor defaults for all other mutators.
What you want invalidates the spec. Eclipse gets beaten up a ton for
not following specifications and it should be a last resort.
> Third, authority: the bean spec is simply not a shining bastion of
> authoritative knowledge and well considered design. Practical virtues
> should not be overthrown merely on the basis of bad phrasing. The
> sentence "May return null if the information should be obtained by
> automatic analysis" is actually non-defining: it does not *preclude* the
> true corollary "if the method returns non-null, other information may be
> obtained by automatic analysis."
I am not going to defend the spec, but we must do all we can to follow
it and being accused of not following a spec is worse than being accused
of doing magic. There is a JSR273 that has just been approved by the
JCP to update the JavaBeans specification and this topic should probably
be raised. By happy coincidence I will be representing IBM on this
expert group so I will bring the topic up, and if it can be shown that
all other tools providers ignore the spec and have sort of implemented
their own variant that has by popular opinion become the new standard
then I would push for the spec to be changed and we'd follow the change.
However we can't just ignore the spec.
> Also, the bean spec does explicitly provide for/require explicit
> property desciptors to take precedence over introspected defaults. So,
> the spirit if not well written letter of the spec intends beaninfos to
> specify only *overrides* of default behavior.
But the letter of the spec doesn't. A computer system can't follow the
spirit of something and not the letter - that's something objective
people can do but not the JVM unfortunately
> Fourth, history: the visual editors and third-party beans/bean suites I
> have encountered make the opposite presumption. For example, beaninfos
> (vis. koders.com) that do not implement property descriptors for all
> mutators do not have to override getAdditionalBeanInfo() to capture
> their obviously missing properties. An override like this would be
> necessary to get back the reasonable behavior:
Wow - I would have thought that three punches were enough to get your
point across. What other tools is a question you should ask of the
other tools.
You do not have to override getAdditionalBeanInfo() for missing
properties. This is for inherited properties.
All you need to do is make sure that the getPropertyDescriptors() method
returns a fully inclusive set. If you want it to include some that you
override and others you don't, then do something like get the set you
want explicit, use reflection to work out the missing ones, and return
these as the set.
> /**
> * Gets a BeanInfo for the <u> naked class </u> of this bean.
> *
> * @return BeanInfo[] containing this bean's native BeanInfo
> */
> public BeanInfo[] getAdditionalBeanInfo() {
> try {
> BeanInfo[] bi = new BeanInfo[1];
> bi[0] = Introspector.getBeanInfo(beanClass,
> Introspector.IGNORE_IMMEDIATE_BEANINFO);
> return bi;
> } catch (IntrospectionException e) {
> throw new Error(e.toString());
> }
> }
>
> Consequently, the correct design choice is to change the behavior of VE
> to automatically add default property descriptions for properties not
> explicitly defined in a Beaninfo. Ultimately, it is a minor change to
> VE, but one that I think will make VE better.
I follow your argument, but not your conclusion.
> Of course, the above getAdditionalBeanInfo() routine is a workaround,
> but only if the beaninfo source is available.
>
> Should I add this as a bug/enhancement request to bugzilla?
Absolutely and we can discuss this further and have it voted on.
Thanks for your arguments and great input - what happened to your
customizer - did you get that working ?
Joe Winchester
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607375 is a reply to message #90268] |
Tue, 10 May 2005 00:01 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Joe,
Thanks for the response. Let me try and sum it up:
Your (the royal you) position is:
1) the spec is clear and you have to follow it
2) cannot do magic
3) must be always mindfull of the principle of least astonishment.
4) what happened to my customizer problem?
My rejoinder is:
1) the spec on point is not clear, certainly not in the King's English
and (watch the toes, apologies in advance) anyone who contends
differently must have an external agenda. There is just nothing in the
language of the spec *itself* that supports the very narrow reading
proposed. And, yes, I am a lawyer (also an EE) quite versed in specs
and licenses. So, if anyone gives you grief on this point, please feel
free to direct them my way for clarification: you cannot get blood from
a stone and if the spec is not objectively clear, you must interpret
(apologies to Johnny), meaning principled analysis of the spirit of the
spec by analogy to related concepts/requirements/constructs and attempt
to remain consistent in the implemented behaviours.
2) the fundamental nature of the Introspector is *magic*, at least if
magic is defined as automatically providing reasonable defaults to
intensionally minimize the work of the programmer and the risk of bugs
in the program (of course, all according to the plan of the Architect
program).
3) for the container example you provided, the construct
public BeanInfo[] getAdditionalBeanInfo() {
return null;
}
is actually quite common in the beaninfos that I have seen. Conversely,
I have yet to find an where anyone has needed or chosen to use the code
presented in my prior post. While the principle of least astonishment
is proper for guidance, no one can just presume to know what others
expect.
Now, I do not presume to know what you (the royal you) know, but my
experience is that my beans work correctly in Jigloo, JDeveloper 9 and
10, JBuilder 7, (a couple I cannot remember at the moment), and Visual
Cafe 4.1. Only now, and only for VE, I am having to patch the beaninfos
to force the visibility of default properties. My well-founded
astonishment is that VE is the odd man out on this point.
Anyway, thats probably enough on this topic. I am glad to hear that you
are on the relevant committees and hope you will support the best
technical (not semantic) argument for most beneficial beaninfo behavior.
If I can be of assistance in that endeavor, please let me know how I can
help.
4) additional information regarding my customizer problem was provided
at the end of my last post. While it shows up in my newsreader, if it
is not visible to you, I could repeat it into a separate thread.
Further, I found the separate VE examples download and will try to get
the ButtonBar customizer sample to work - or were you referring to a
differnt/better Swing example used to confirm customizer operation?
Thanks,
Gerald
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607382 is a reply to message #90283] |
Tue, 10 May 2005 09:38 |
Joe Winchester
Messages: 496
Registered: July 2009 |
Senior Member |
|
|
Gerald Rosenberg wrote:
> Now, I do not presume to know what you (the royal you) know, but my
> experience is that my beans work correctly in Jigloo, JDeveloper 9 and
> 10, JBuilder 7, (a couple I cannot remember at the moment), and Visual
> Cafe 4.1. Only now, and only for VE, I am having to patch the beaninfos
> to force the visibility of default properties. My well-founded
> astonishment is that VE is the odd man out on this point.
For various reasons that I am sure you appreicate it is hard for us to
look directly at other tools, however we do not wish to be inconsistent
and I do take all your arguments as valid.
I have e-mailed the Sun engineer who looks after the JavaBeans
specification to ask for their clarification on this position and I will
try to get a discusson on this as soon as possible on JSR273 JavaBeans
expert group. We will do whatever the spec says, and if the spec has to
be amended to follow what is de-facto implementation then we will
support the change and follow the new amendment.
> Anyway, thats probably enough on this topic. I am glad to hear that you
> are on the relevant committees and hope you will support the best
> technical (not semantic) argument for most beneficial beaninfo behavior.
> If I can be of assistance in that endeavor, please let me know how I can
> help.
This would be great. If you could please write up a document that
describes the behavior you see with various tools and point out how this
is inconsistent with the spec that would be great. Try to go easy on
the emotional arguments and make it very matter of fact. You can either
post this to the newsgroup or just e-mail it to me directly.
> 4) additional information regarding my customizer problem was provided
> at the end of my last post. While it shows up in my newsreader, if it
> is not visible to you, I could repeat it into a separate thread.
Glad you fixed it - I am curious what the problem was. Is it something
we could improve in the VE editor >
> Further, I found the separate VE examples download and will try to get
> the ButtonBar customizer sample to work - or were you referring to a
> differnt/better Swing example used to confirm customizer operation?
Our examples plugin is sort of in flux - the one I actually used was
Area in our org.eclipse.ve.examples.
Best regards,
Joe
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607392 is a reply to message #90385] |
Tue, 10 May 2005 17:24 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
In article <d5pvt7$jcn$1@news.eclipse.org>, winchest@uk.ibm.com says...
> Gerald Rosenberg wrote:
>
> > Anyway, thats probably enough on this topic. I am glad to hear that you
> > are on the relevant committees and hope you will support the best
> > technical (not semantic) argument for most beneficial beaninfo behavior.
> > If I can be of assistance in that endeavor, please let me know how I can
> > help.
>
> This would be great. If you could please write up a document that
> describes the behavior you see with various tools and point out how this
> is inconsistent with the spec that would be great. Try to go easy on
> the emotional arguments and make it very matter of fact. You can either
> post this to the newsgroup or just e-mail it to me directly.
>
> > 4) additional information regarding my customizer problem was provided
> > at the end of my last post. While it shows up in my newsreader, if it
> > is not visible to you, I could repeat it into a separate thread.
>
> Glad you fixed it - I am curious what the problem was. Is it something
> we could improve in the VE editor >
>
Looks like two changes are needed.
1) VE throws a class not found error if the BeanDescriptor returned by
getBeanDescriptor() includes a FeatureDescriptor key and value of
"customizerClass" and the customizer class.
Specifically, this works:
public BeanDescriptor getBeanDescriptor1() {
BeanDescriptor result = new BeanDescriptor(
JStatusBar.class, ColorCustomizer.class);
return result;
}
This does not:
public BeanDescriptor getBeanDescriptor1() {
BeanDescriptor result = new BeanDescriptor(
JStatusBar.class, ColorCustomizer.class);
result.setValue("customizerClass", ColorCustomizer.class);
return result;
}
Obviously, adding the customizer to the FeatureDescriptor is not
necessary, but it is what is done by default by Sun's own SwingBeanInfo
class (the one in Sun's dt.jar through 1.4.x). See,
SwingBeanInfo#createBeanDescriptor(Class cls, Object[] args).
2) Seems that VE is calling getDefaultPropertyIndex() on all properties,
not just indexed properties. If anything other than -1 is returned for
a non-indexed property, I get a fatal null pointer exception from the
remote VM (below). VE needs to be more selective in when it calls
getDefaultPropertyIndex().
Regards,
Gerald
!ENTRY org.eclipse.jem.beaninfo 2 0 2005-05-10 10:07:01.551
!MESSAGE IWAV0155E Introspection failed on class
"net.certiv.swing.JStatusBar." msg="."
!STACK 0
IWAV0073I *** RemoteVM Exception - Trace from Remote VM:
java.lang.NullPointerException
at java.beans.Introspector.getTargetPropertyInfo
(Introspector.java:477)
at java.beans.Introspector.getBeanInfo(Introspector.java:385)
at java.beans.Introspector.getBeanInfo(Introspector.java:155)
at
org.eclipse.jem.internal.beaninfo.vm.ModelingBeanInfo.intros pect
(ModelingBeanInfo.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.jem.internal.proxy.vm.remote.ConnectionHandler.r un
(ConnectionHandler.java:316)
at org.eclipse.jem.internal.proxy.vm.remote.ConnectionThread.ru n
(ConnectionThread.java:47)
IWAV0074I *** Local StackTrace:
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanProxyP roxy:
java.lang.NullPointerException
at
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.createTh
rowableBeanProxy(REMThrowableBeanTypeProxy.java:34)
at
org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.newBeanP
roxy(REMThrowableBeanTypeProxy.java:65)
at
org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.getBea
nProxy(REMStandardBeanProxyFactory.java:454)
at
org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.proces
sErrorReturn(REMStandardBeanProxyFactory.java:505)
at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
(REMMethodProxy.java:216)
at
org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invokeW ithParms
(REMMethodProxy.java:175)
at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
(REMMethodProxy.java:101)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ct(BeaninfoClassAdapter.java:756)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ctIfNecessary(BeaninfoClassAdapter.java:472)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
ctIfNecessary(BeaninfoClassAdapter.java:459)
at
org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.getEStru
cturalFeatures(BeaninfoClassAdapter.java:1070)
at org.eclipse.jem.java.impl.JavaClassImpl.getEStructuralFeatur es
(JavaClassImpl.java:382)
at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributesGen
(EClassImpl.java:204)
at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributes
(EClassImpl.java:242)
at org.eclipse.emf.ecore.impl.EClassImpl.getEIDAttribute
(EClassImpl.java:136)
at org.eclipse.emf.ecore.util.EcoreUtil.getID(EcoreUtil.java:24 80)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragm ent
(ResourceImpl.java:529)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.getURIFragmen t
(XMLResourceImpl.java:355)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getURIFragment
(XMLHelperImpl.java:617)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getIDREF
(XMLHelperImpl.java:631)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveIDRefSingle
(XMLSaveImpl.java:1602)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
(XMLSaveImpl.java:1015)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
(XMLSaveImpl.java:2214)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement
(XMLSaveImpl.java:885)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany
(XMLSaveImpl.java:1943)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
(XMLSaveImpl.java:1208)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
(XMLSaveImpl.java:2214)
at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects
(XMISaveImpl.java:76)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse
(XMLSaveImpl.java:474)
at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save
(XMLSaveImpl.java:204)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave
(XMLResourceImpl.java:192)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
(ResourceImpl.java:893)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
(ResourceImpl.java:813)
at
org.eclipse.ve.internal.java.codegen.util.VEModelCacheUtilit y.doSaveCach
e(VEModelCacheUtility.java:154)
at
org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslat or.doSave
(JavaSourceTranslator.java:1368)
at
org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart.doS
ave(JavaVisualEditorPart.java:2498)
at org.eclipse.ui.internal.EditorManager$8.run
(EditorManager.java:1386)
at org.eclipse.ui.internal.SaveableHelper$2.run
(SaveableHelper.java:116)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread
(ModalContext.java:346)
at org.eclipse.jface.operation.ModalContext.run
(ModalContext.java:291)
at org.eclipse.jface.window.ApplicationWindow$1.run
(ApplicationWindow.java:624)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.jface.window.ApplicationWindow.run
(ApplicationWindow.java:621)
at org.eclipse.ui.internal.WorkbenchWindow.run
(WorkbenchWindow.java:1975)
at
org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOpe ration
(SaveableHelper.java:122)
at org.eclipse.ui.internal.EditorManager.saveAll
(EditorManager.java:1406)
at org.eclipse.ui.internal.Workbench$11.run(Workbench.java:579)
at org.eclipse.core.internal.runtime.InternalPlatform.run
(InternalPlatform.java:1021)
at org.eclipse.core.runtime.Platform.run(Platform.java:757)
at org.eclipse.ui.internal.Workbench.saveAllEditors
(Workbench.java:550)
at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:4 70)
at org.eclipse.ui.internal.Workbench.access$6(Workbench.java:46 1)
at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:645)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:643)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:618)
at org.eclipse.ui.internal.WorkbenchWindow.busyClose
(WorkbenchWindow.java:536)
at org.eclipse.ui.internal.WorkbenchWindow.access$0
(WorkbenchWindow.java:520)
at org.eclipse.ui.internal.WorkbenchWindow$1.run
(WorkbenchWindow.java:621)
at org.eclipse.swt.custom.BusyIndicator.showWhile
(BusyIndicator.java:69)
at org.eclipse.ui.internal.WorkbenchWindow.close
(WorkbenchWindow.java:619)
at org.eclipse.jface.window.Window.handleShellCloseEvent
(Window.java:721)
at org.eclipse.jface.window.Window$3.shellClosed(Window.java:66 8)
at org.eclipse.swt.widgets.TypedListener.handleEvent
(TypedListener.java:158)
at org.eclipse.swt.widgets.EventTable.sendEvent
(EventTable.java:82)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851)
at org.eclipse.swt.widgets.Decorations.closeWidget
(Decorations.java:256)
at org.eclipse.swt.widgets.Decorations.WM_CLOSE
(Decorations.java:1568)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3031 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
at org.eclipse.swt.widgets.Decorations.windowProc
(Decorations.java:1493)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native
Method)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 25)
at org.eclipse.swt.widgets.Display.readAndDispatch
(Display.java:2525)
at org.eclipse.ui.internal.Workbench.runEventLoop
(Workbench.java:1570)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1534)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench
(Workbench.java:306)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench
(PlatformUI.java:143)
at org.eclipse.ui.internal.ide.IDEApplication.run
(IDEApplication.java:103)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run
(PlatformActivator.java:228)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run
(EclipseStarter.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:315 )
at org.eclipse.core.launcher.Main.basicRun(Main.java:268)
at org.eclipse.core.launcher.Main.run(Main.java:942)
at org.eclipse.core.launcher.Main.main(Main.java:926)
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607393 is a reply to message #90530] |
Tue, 10 May 2005 18:55 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
Thanks for the info but we need a little more info please:
For the following, please tell me what JDK, and VE are you using. We
never look at "customizerClass" attributes. Is there a log trace where
you get this classNotFound message. That would be helpful. Then we can
trace why you get this and fix it.
>
> Looks like two changes are needed.
>
> 1) VE throws a class not found error if the BeanDescriptor returned by
> getBeanDescriptor() includes a FeatureDescriptor key and value of
> "customizerClass" and the customizer class.
>
> Specifically, this works:
>
> public BeanDescriptor getBeanDescriptor1() {
> BeanDescriptor result = new BeanDescriptor(
> JStatusBar.class, ColorCustomizer.class);
> return result;
> }
>
> This does not:
>
> public BeanDescriptor getBeanDescriptor1() {
> BeanDescriptor result = new BeanDescriptor(
> JStatusBar.class, ColorCustomizer.class);
> result.setValue("customizerClass", ColorCustomizer.class);
> return result;
> }
>
> Obviously, adding the customizer to the FeatureDescriptor is not
> necessary, but it is what is done by default by Sun's own SwingBeanInfo
> class (the one in Sun's dt.jar through 1.4.x). See,
> SwingBeanInfo#createBeanDescriptor(Class cls, Object[] args).
>
For the following, default property index has nothing to do with indexed
properties. The index returned is the index of the property within the
array of properties returned for this bean that is the default property.
It is not called on any properties, it is a method on the BeanInfo
class, so it is called only once. So the number returned (if not -1)
must be within the range of 0 to one less than the size of the array of
properties for the bean. This is a java.beans.BeanDescriptor
requirement, not a VE requirement.
Here is the comment for the code directly out of the JDK:
/**
* A bean may have a "default" property that is the property that will
* mostly commonly be initially chosen for update by human's who are
* customizing the bean.
* @return Index of default property in the PropertyDescriptor array
* returned by getPropertyDescriptors.
* <P> Returns -1 if there is no default property.
*/
Unfortunately your Introspector class (which is from the JDK) is
different than mine so the line numbers don't match up. From looking at
the Java Introspector code, the only way I could think of that returning
something other than -1 is if the BeanInfo that is returning the index
IS NOT returning an array from the getProperties() call. The index
returned is supposed to be within the range of the properties from the
getProperties() method on the BeanInfo. This is invalid.
> 2) Seems that VE is calling getDefaultPropertyIndex() on all properties,
> not just indexed properties. If anything other than -1 is returned for
> a non-indexed property, I get a fatal null pointer exception from the
> remote VM (below). VE needs to be more selective in when it calls
> getDefaultPropertyIndex().
>
> Regards,
> Gerald
>
>
>
>
> !ENTRY org.eclipse.jem.beaninfo 2 0 2005-05-10 10:07:01.551
> !MESSAGE IWAV0155E Introspection failed on class
> "net.certiv.swing.JStatusBar." msg="."
> !STACK 0
> IWAV0073I *** RemoteVM Exception - Trace from Remote VM:
> java.lang.NullPointerException
> at java.beans.Introspector.getTargetPropertyInfo
> (Introspector.java:477)
> at java.beans.Introspector.getBeanInfo(Introspector.java:385)
> at java.beans.Introspector.getBeanInfo(Introspector.java:155)
> at
> org.eclipse.jem.internal.beaninfo.vm.ModelingBeanInfo.intros pect
> (ModelingBeanInfo.java:182)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.jem.internal.proxy.vm.remote.ConnectionHandler.r un
> (ConnectionHandler.java:316)
> at org.eclipse.jem.internal.proxy.vm.remote.ConnectionThread.ru n
> (ConnectionThread.java:47)
> IWAV0074I *** Local StackTrace:
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanProxyP roxy:
> java.lang.NullPointerException
> at
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.createTh
> rowableBeanProxy(REMThrowableBeanTypeProxy.java:34)
> at
> org.eclipse.jem.internal.proxy.remote.REMThrowableBeanTypePr oxy.newBeanP
> roxy(REMThrowableBeanTypeProxy.java:65)
> at
> org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.getBea
> nProxy(REMStandardBeanProxyFactory.java:454)
> at
> org.eclipse.jem.internal.proxy.remote.REMStandardBeanProxyFa ctory.proces
> sErrorReturn(REMStandardBeanProxyFactory.java:505)
> at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
> (REMMethodProxy.java:216)
> at
> org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invokeW ithParms
> (REMMethodProxy.java:175)
> at org.eclipse.jem.internal.proxy.remote.REMMethodProxy.invoke
> (REMMethodProxy.java:101)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ct(BeaninfoClassAdapter.java:756)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ctIfNecessary(BeaninfoClassAdapter.java:472)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.introspe
> ctIfNecessary(BeaninfoClassAdapter.java:459)
> at
> org.eclipse.jem.internal.beaninfo.adapters.BeaninfoClassAdap ter.getEStru
> cturalFeatures(BeaninfoClassAdapter.java:1070)
> at org.eclipse.jem.java.impl.JavaClassImpl.getEStructuralFeatur es
> (JavaClassImpl.java:382)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributesGen
> (EClassImpl.java:204)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEAllAttributes
> (EClassImpl.java:242)
> at org.eclipse.emf.ecore.impl.EClassImpl.getEIDAttribute
> (EClassImpl.java:136)
> at org.eclipse.emf.ecore.util.EcoreUtil.getID(EcoreUtil.java:24 80)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIFragm ent
> (ResourceImpl.java:529)
> at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.getURIFragmen t
> (XMLResourceImpl.java:355)
> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getURIFragment
> (XMLHelperImpl.java:617)
> at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getIDREF
> (XMLHelperImpl.java:631)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveIDRefSingle
> (XMLSaveImpl.java:1602)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
> (XMLSaveImpl.java:1015)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
> (XMLSaveImpl.java:2214)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElement
> (XMLSaveImpl.java:885)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveContainedMany
> (XMLSaveImpl.java:1943)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveFeatures
> (XMLSaveImpl.java:1208)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.saveElementID
> (XMLSaveImpl.java:2214)
> at org.eclipse.emf.ecore.xmi.impl.XMISaveImpl.writeTopObjects
> (XMISaveImpl.java:76)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.traverse
> (XMLSaveImpl.java:474)
> at org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl.save
> (XMLSaveImpl.java:204)
> at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doSave
> (XMLResourceImpl.java:192)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
> (ResourceImpl.java:893)
> at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save
> (ResourceImpl.java:813)
> at
> org.eclipse.ve.internal.java.codegen.util.VEModelCacheUtilit y.doSaveCach
> e(VEModelCacheUtility.java:154)
> at
> org.eclipse.ve.internal.java.codegen.core.JavaSourceTranslat or.doSave
> (JavaSourceTranslator.java:1368)
> at
> org.eclipse.ve.internal.java.codegen.editorpart.JavaVisualEd itorPart.doS
> ave(JavaVisualEditorPart.java:2498)
> at org.eclipse.ui.internal.EditorManager$8.run
> (EditorManager.java:1386)
> at org.eclipse.ui.internal.SaveableHelper$2.run
> (SaveableHelper.java:116)
> at org.eclipse.jface.operation.ModalContext.runInCurrentThread
> (ModalContext.java:346)
> at org.eclipse.jface.operation.ModalContext.run
> (ModalContext.java:291)
> at org.eclipse.jface.window.ApplicationWindow$1.run
> (ApplicationWindow.java:624)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.jface.window.ApplicationWindow.run
> (ApplicationWindow.java:621)
> at org.eclipse.ui.internal.WorkbenchWindow.run
> (WorkbenchWindow.java:1975)
> at
> org.eclipse.ui.internal.SaveableHelper.runProgressMonitorOpe ration
> (SaveableHelper.java:122)
> at org.eclipse.ui.internal.EditorManager.saveAll
> (EditorManager.java:1406)
> at org.eclipse.ui.internal.Workbench$11.run(Workbench.java:579)
> at org.eclipse.core.internal.runtime.InternalPlatform.run
> (InternalPlatform.java:1021)
> at org.eclipse.core.runtime.Platform.run(Platform.java:757)
> at org.eclipse.ui.internal.Workbench.saveAllEditors
> (Workbench.java:550)
> at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:4 70)
> at org.eclipse.ui.internal.Workbench.access$6(Workbench.java:46 1)
> at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:645)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.ui.internal.Workbench.close(Workbench.java:643)
> at org.eclipse.ui.internal.Workbench.close(Workbench.java:618)
> at org.eclipse.ui.internal.WorkbenchWindow.busyClose
> (WorkbenchWindow.java:536)
> at org.eclipse.ui.internal.WorkbenchWindow.access$0
> (WorkbenchWindow.java:520)
> at org.eclipse.ui.internal.WorkbenchWindow$1.run
> (WorkbenchWindow.java:621)
> at org.eclipse.swt.custom.BusyIndicator.showWhile
> (BusyIndicator.java:69)
> at org.eclipse.ui.internal.WorkbenchWindow.close
> (WorkbenchWindow.java:619)
> at org.eclipse.jface.window.Window.handleShellCloseEvent
> (Window.java:721)
> at org.eclipse.jface.window.Window$3.shellClosed(Window.java:66 8)
> at org.eclipse.swt.widgets.TypedListener.handleEvent
> (TypedListener.java:158)
> at org.eclipse.swt.widgets.EventTable.sendEvent
> (EventTable.java:82)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851)
> at org.eclipse.swt.widgets.Decorations.closeWidget
> (Decorations.java:256)
> at org.eclipse.swt.widgets.Decorations.WM_CLOSE
> (Decorations.java:1568)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3031 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
> at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method)
> at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:1620 )
> at org.eclipse.swt.widgets.Shell.callWindowProc(Shell.java:403)
> at org.eclipse.swt.widgets.Control.windowProc(Control.java:3114 )
> at org.eclipse.swt.widgets.Decorations.windowProc
> (Decorations.java:1493)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466 )
> at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native
> Method)
> at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:16 25)
> at org.eclipse.swt.widgets.Display.readAndDispatch
> (Display.java:2525)
> at org.eclipse.ui.internal.Workbench.runEventLoop
> (Workbench.java:1570)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1534)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench
> (Workbench.java:306)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench
> (PlatformUI.java:143)
> at org.eclipse.ui.internal.ide.IDEApplication.run
> (IDEApplication.java:103)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run
> (PlatformActivator.java:228)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run
> (EclipseStarter.java:344)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run
> (EclipseStarter.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:315 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:268)
> at org.eclipse.core.launcher.Main.run(Main.java:942)
> at org.eclipse.core.launcher.Main.main(Main.java:926)
--
Thanks,
Rich Kulp
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607394 is a reply to message #90545] |
Tue, 10 May 2005 21:49 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
In article <d5r0ih$1df$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> Thanks for the info but we need a little more info please:
>
> For the following, please tell me what JDK, and VE are you using. We
> never look at "customizerClass" attributes. Is there a log trace where
> you get this classNotFound message. That would be helpful. Then we can
> trace why you get this and fix it.
>
JDK1.5
Eclipse 3.1M6
EMF build I200504141117
GEF Build 3.1M6
VE-runtime-1.1M1
You should be able to reproduce the error from the code provided in the
prior post - just add the one line to the AreaBeanInfo. I will get you
a stack trace from my system shortly.
FWIW, my guess is that whatever code is evaluating the feature
descriptor is recognizing the customizer class, if not by key then as a
class object, and tries to load it, resulting in the not found error.
> Unfortunately your Introspector class (which is from the JDK) is
> different than mine so the line numbers don't match up. From looking at
> the Java Introspector code, the only way I could think of that returning
> something other than -1 is if the BeanInfo that is returning the index
> IS NOT returning an array from the getProperties() call.
I will recheck my code. To be sure, Sun's SwingBeanInfo overrides
getDefaultPropertyIndex() to *always* return 0. My beaninfos extend
SwingBeanInfo but do not further override getDefaultPropertyIndex().
Commenting out getDefaultPropertyIndex() in SwingBeanInfo - exposing
getDefaultPropertyIndex() in SimpleBeanInfo - removes the error.
I have been using Sun's SwingBeanInfo simply because that is what Sun's
own beaninfos use (or used). As of 1.5, it seems that Sun has switched
to SwingBeanInfoBase (http://java.sun.com/j2se/1.5.0/jcp/beta2/).
Two notable details: logging shows that SwingBeanInfoBase still loads
the feature descriptor with the customizer class and still overrides
getDefaultPropertyIndex() to always return a value of 0.
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607395 is a reply to message #90559] |
Tue, 10 May 2005 22:51 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
As for the customizer problem, I think I know what's wrong. Please open
a Bugzilla against VE project, Java Model (JEM) component so that we can
fix it and track it.
For the default property index, my presumption is that they expect only
javax.swing classes to use SwingBeanInfo, and nobody else. The
specification for SwingBeanInfoBase specifies that it is only for
javax.swing classes. And I guess all Swing BeanInfo's will return
something from getPropertyDescriptors() AND the first descriptor will be
the default property.
The spec from the link in the append indicates:
>> However, products that ship BeanInfos in the javax.swing namespace
>> and that are based on or targeted for J2SE 1.6 will be required to
>> conform to the Swing BeanInfo optional package specification.
This implies that if not for javax.swing, then it should not be used.
--
Thanks,
Rich Kulp
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607396 is a reply to message #90576] |
Wed, 11 May 2005 03:48 |
Gerald Rosenberg
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
In article <d5red0$h1e$1@news.eclipse.org>, richkulp@us.NO_SPAM.ibm.com
says...
> As for the customizer problem, I think I know what's wrong. Please open
> a Bugzilla against VE project, Java Model (JEM) component so that we can
> fix it and track it.
Bug 94587
> For the default property index, my presumption is that they expect only
> javax.swing classes to use SwingBeanInfo, and nobody else. The
> specification for SwingBeanInfoBase specifies that it is only for
> javax.swing classes. And I guess all Swing BeanInfo's will return
> something from getPropertyDescriptors() AND the first descriptor will be
> the default property.
>
> The spec from the link in the append indicates:
>
> >> However, products that ship BeanInfos in the javax.swing namespace
> >> and that are based on or targeted for J2SE 1.6 will be required to
> >> conform to the Swing BeanInfo optional package specification.
>
> This implies that if not for javax.swing, then it should not be used.
Well, I would agree that Sun does not make it particularly easy to use
given the nearly hidden source and dearth of documentation.
So, from your suggestion not to use the Sun classes, what is a better
helper class to use - writing directly to SimpleBeanInfo is just plain
clumsy and error prone. What convenience class do you use or recommend?
|
|
|
| Re: Clarifications on using BeanInfo customizers? [message #607398 is a reply to message #90590] |
Wed, 11 May 2005 14:08 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
We actually wrote our own. You can copy it and use it if you wish.
Unless you will only be running your BeanInfo within the VE environment,
I don't recommend using our class directly. Because it would not be
available outside of VE environment unless you copy the one class. It is
Opensource, so you can copy it if you follow the Eclipse license just
for that class.
It is called BaseBeanInfo and is in the org.eclipse.jem.beaninfo plugin.
You can get the source either from Eclipse CVS directly or from the
source jar inside
org.eclipse.jem.sdk/src/org.eclipse.jem.beaninfo/vm/beaninfo src.zip.
--
Thanks,
Rich Kulp
|
|
| |
Goto Forum:
Current Time: Sat Nov 09 23:13:26 GMT 2024
Powered by FUDForum. Page generated in 0.06028 seconds |
] 
Search
Help
Register
Login
Home
