4:47 p.m.
Hi guys,
Was looking at how EXIN-240 was implemented in ReportProblemWizard and I
noticed some things that raised some questions. Would be good to hear
the answer to them ;)
1) Custom Preferences?
I noticed org.jboss.tools.common.model.ui.reporting.ReportPreference
was used - what are these Preference things ? It looks similar to
Eclipse Preferences but I have a feeling that is not the case...what are
they and why are the "path" hardcoded to "Struts Studio" ?
Why aren't these just normal eclipse properties ?
Where are they stored ?
How can the user toggle them ?
2) ATT_ATTACH_REDHAT_LOG and ATT_ATTACH_ECLIPSE_LOG
What is REDHAT_LOG ?
Why aren't these attributes used for anything ?
Attaching the eclipse log would be an relavant option.
3) What is AbstractQueryWizard ? The dialog extends it but what does it
help with ?
4) The layout looks weird on linux - the right side of all the text
fields are chopped of (the dialog is to narrow) - note commenting out
the hard coded getPreferredSize did not help, it just made it worse.
5) what is XAttributeSupport ?
6)
6:12 p.m.
4) The layout looks weird on linux - the right side of all the text
fields are chopped of (the dialog is to narrow) - note commenting out
the hard coded getPreferredSize did not help, it just made it worse.
Fixed this issue and a bunch of other simplifications in the code.
Found some more questions ;)
1) ClassLoaderUtil.init() ?
Why is ClassLoaderUtil.init() placed in ReportProblemAction.run() ?
When is that needed ?
Removing it gives a weird error:
"Can't create new JBoss Server."
java.lang.NullPointerException
at
org.jboss.tools.common.model.options.Preference.getValue(Preference.java:33)
at
org.jboss.tools.common.model.options.PreferenceModelUtilities.initPreferenceValue(PreferenceModelUtilities.java:69)
at
org.jboss.tools.jst.web.WebModelPlugin.initializeDefaultPluginPreferences(WebModelPlugin.java:97)
at
org.eclipse.core.runtime.Plugin.internalInitializeDefaultPluginPreferences(Plugin.java:449)
at
org.eclipse.core.internal.preferences.legacy.InitLegacyPreferences.init(InitLegacyPreferences.java:52)
at
org.eclipse.core.internal.preferences.PreferenceServiceRegistryHelper.applyRuntimeDefaults(PreferenceServiceRegistryHelper.java:146)
Why?
2) Is there some crazy heavy initialization required to show the Report
Problem dialog ?
It takes seconds before it shows up the first time (not done anything
else) ....what is going on ? Is XModel loading the whole world ?
3) Resource keys
There is a plugin.properties file with localization properties, e.g.
action.reportproblem.label=Report Problem
Inside ReportProblemAction, .setObject(properties) are used to
initialize headers - where are the localization files for these strings
? e.g. subtitle, header etc. ?
/max
6:44 p.m.
3) Resource keys
There is a plugin.properties file with localization properties, e.g.
action.reportproblem.label=Report Problem
Inside ReportProblemAction, .setObject(properties) are used to
initialize headers - where are the localization files for these strings
? e.g. subtitle, header etc. ?
Found them in
org.jboss.tools.common.model/resources/help/key-model.properties
(weird location since they are pure UI strings)
What decides the name of that file ? "help/key-model.properties" ?
Anyhow it still did not work because AbstractQueryWizard had a bug with
respect to setting Message label (JBIDE-560), but its fixed now.
/max
6:59 a.m.
New subject: Questions found while looking at report problemreimplementation
1) Custom Preferences?
Why aren't these just normal eclipse properties ?
The
Exadel framework for prefernces was created a long ago
and migrated to Eclipse with minimal changes. It describes preferences in terms
of XModel which allows to reuse in preference pages same forms that are
used in editors and dialogs
(org.jboss.tools.common.model.ui.preferences.XMOBasedPreferencesPage).
ReportPreference is a utility class accessing the XModel object keeping the
preferences. "Struts Studio" is an awkward slip, it can be fixed.
Where are they stored ?
%workspace%/.metadata/.plugins/org.jboss.tools.common.model/Preferences.xml
How can the user toggle them ?
There was preference page
'Report Problem'. Someone removed it when
migrating to RedHat. It is quite easy to restore it.
Also, some of these preferences are saved according to user
choice in checkboxes in
org.jboss.tools.common.model.ui.dialog.ErrorDialog
2) ATT_ATTACH_REDHAT_LOG and ATT_ATTACH_ECLIPSE_LOG
What is REDHAT_LOG ?
%workspace%/.metadata/.plugins/org.jboss.tools.common/.log
When error dialog appears it prompts user either to report problem immediately
or to save it into that log to be sent at a later time (by action Report Problem).
Why aren't these attributes used for anything ?
Attaching the eclipse log would be an relavant option.
ATT_ATTACH_REDHAT_LOG is used - when reporting a problem user may
type a letter without attaching content of the log (result of previously preferring
to postpone reporting in error dialog).
ATT_ATTACH_ECLIPSE_LOG had been used in the same way, but later was
commented out from ReportProblemWizard (I do not remember exact reason,
maybe a caution because eclipse log may be quite lo-o-ong).
3) What is AbstractQueryWizard ? The dialog extends it but what does
it
help with ?
Again, this framework for dialogs was developed a long before Eclipse epoch
and migrated to Eclipse with reimplementing AbstractQueryDialog that extends
standard TitleAreaDialog. AbstractQueryWizard implements SpecialWizard
which makes it a common service that can be loaded by id and executed
without bothering if it is a dialog or not.
4) The layout looks weird on linux
That must be studied and
fixed. In Windows dialog looked fine.
5) what is XAttributeSupport ?
It manages an input form in dialogs, editors and
preferences.
A set of input fields is described in XModel metadata.
This approach is very helpful because it sets the standard for all forms,
and in most cases allows to create a form just putting few tags to
*.meta file.
Slava Kabanovich
11:02 a.m.
New subject: Questions found while looking at report problemreimplementation
1) Custom Preferences?
> Why aren't these just normal eclipse properties ?
The Exadel framework for prefernces was created a long ago
and migrated to Eclipse with minimal changes. It describes preferences
in terms
of XModel which allows to reuse in preference pages same forms that are
used in editors and dialogs
(org.jboss.tools.common.model.ui.preferences.XMOBasedPreferencesPage).
okey...I would just wish the code was simpler - or at least typesafe ;)
ReportPreference is a utility class accessing the XModel object
keeping the
preferences. "Struts Studio" is an awkward slip, it can be fixed.
Well its a pretty big "slip" since it occurs about 47 times in the code
base :)
> Where are they stored ?
%workspace%/.metadata/.plugins/org.jboss.tools.common.model/Preferences.xml
hmm - I can't find such file in any of the workspaces I have run jboss
tools with ? the only one I can see is .rule-sets.xml which I also is
wondering why is there ;)
> How can the user toggle them ?
There was preference page 'Report Problem'. Someone removed it when
migrating to RedHat. It is quite easy to restore it.
Ok - we should do that. How is that enabled ?
Also, some of these preferences are saved according to user
choice in checkboxes in
org.jboss.tools.common.model.ui.dialog.ErrorDialog
How does that dialog relate to the "report problems" dialog ?
> 2) ATT_ATTACH_REDHAT_LOG and ATT_ATTACH_ECLIPSE_LOG
> What is REDHAT_LOG ?
%workspace%/.metadata/.plugins/org.jboss.tools.common/.log
When error dialog appears it prompts user either to report problem
immediately
or to save it into that log to be sent at a later time (by action Report
Problem).
How can I reproduce this ?
> Why aren't these attributes used for anything ?
> Attaching the eclipse log would be an relavant option.
ATT_ATTACH_REDHAT_LOG is used - when reporting a problem user may
type a letter without attaching content of the log (result of
previously preferring
to postpone reporting in error dialog).
Ok - so we should have a checkbox in the report problem dialog for this.
ATT_ATTACH_ECLIPSE_LOG had been used in the same way, but later was
commented out from ReportProblemWizard (I do not remember exact reason,
maybe a caution because eclipse log may be quite lo-o-ong).
solvable by only including a subset of it (e.g. the 100 last lines or
lines since the latest startup or something like newer than 2 days or
something)
> 3) What is AbstractQueryWizard ? The dialog extends it but what
does it
> help with ?
Again, this framework for dialogs was developed a long before Eclipse epoch
and migrated to Eclipse with reimplementing AbstractQueryDialog that
extends
standard TitleAreaDialog. AbstractQueryWizard implements SpecialWizard
which makes it a common service that can be loaded by id and executed
without bothering if it is a dialog or not.
When is it not a dialog ?
> 4) The layout looks weird on linux
That must be studied and fixed. In Windows dialog looked fine.
I fixed it - there was not width hint so the preferredsize was being
honored but the width of the textfield was as big as the text inside it.
> 5) what is XAttributeSupport ?
It manages an input form in dialogs, editors and preferences.
A set of input fields is described in XModel metadata.
This approach is very helpful because it sets the standard for all forms,
and in most cases allows to create a form just putting few tags to
*.meta file.
Can you point me to an example of this ?
The ReportProblemWizard has alot of ui code so I assume it is not a
good example of xattributesupport usage?
/max
12:16 p.m.
New subject: Questions found while looking at report problemreimplementation
> 1) Custom Preferences?
> (org.jboss.tools.common.model.ui.preferences.XMOBasedPreferencesPage).
>
%workspace%/.metadata/.plugins/org.jboss.tools.common.model/Preferences.xml
hmm - I can't find such file in any of the workspaces I have run jboss
tools with ? the only one I can see is .rule-sets.xml which I also is
wondering why is there ;)
It appears their only after user changes preferences in dialog.
.rule-sets.xml keeps preferences for verification rules (jsf and struts)
edited on page RedHat/Verification That is one more example of our
old framework.
> There was preference page 'Report Problem'. Someone
removed it when
> migrating to RedHat. It is quite easy to restore it.
Ok - we should do that. How is that enabled ?
ReportProblemPreferencesPage should be registered in plugin.xml as preference page, I will
do it.
How does that dialog relate to the "report problems" dialog
?
Example:
ProblemReportingHelper.reportProblem(WebUiPlugin.PLUGIN_ID, "Exception caught in
AppRegisterWizard.performFinish(): " + ex.getMessage(), ex);
that results in opening our error dialog.
The idea was to prompt users to report problems, by showing this dialog instead of silent
writing to log. Also, only through this call the redhat log we discussed can be filled
with
problems most interesting to us (we can define places for that by call as above example),
while writing to Eclipse log mixes our errors with other stuff that maybe of not much
interest.
Now, I checked in the workspace and found that ProblemReportingHelper is used much
less than it used to. For instance, most often used class DefaultSpecialWizard made
such call and now it is replaced with silent logging. Should not we resume the practice of
using this error dialog more often?
> > 2) ATT_ATTACH_REDHAT_LOG and ATT_ATTACH_ECLIPSE_LOG
> > What is REDHAT_LOG ?
>
How can I reproduce this ?
Insert call to ProblemReportingHelper to any part of
code and pass it exception instance.
> > 3) What is AbstractQueryWizard ? The dialog extends it but
what does it
> > help with ?
> AbstractQueryWizard implements SpecialWizard
When is it not a dialog ?
I mean that SpecialWizard has a lot of implementations that are not dialogs.
> > 4) The layout looks weird on linux
Well, I think that problem appeared after swt widgets were added to
that dialog in addition to XAttributeSupport that behaves quite well.
> > 5) what is XAttributeSupport ?
Can you point me to an example of this ?
The ReportProblemWizard has alot of ui code so I assume it is not a
good example of xattributesupport usage?
As I understood after having refreshed this class, someone else added
swt components to it instead of extending meta data for used support.
So result is a cumbersome change of two approaches.
Nice examples:
XMOBasedPreferencesPage - base for most model preference pages
SpecialWizardStep - default page for most dialogs for XModel.
Form - default implementation for most forms in editors,
it is more complex because it adds table for lists of child objects,
but part for attributes is simple enough.
Slava Kabanovich
12:16 p.m.
New subject: Seam Scanner for class files
JDT does not include annotations into java model.
By now, java.lang.Class is used to load annotations.
To obtain Class objects, class loader is created for
user project. That way seems to be quite fast and reliable.
I have found that jdt uses
org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader
to load java model, and probably it provides all required information
about annotations, but that needs some more studies.
I think that for the time being we may use java.lang.Class-based
implementation to attend other urgent issues, and replace it
with ClassFileReader-based implementation later if time allows.
Slava Kabanovich
12:23 p.m.
New subject: Seam Scanner for class files
JDT does not include annotations into java model.
true, but that is why you use something like APT does and reads the
annotations. e.g. use the compilation participant and parse the source
and you can visit the nodes. I did that in my initial prototype,
unfortunatly i don't have the code on my laptop. I'll post it when I
find it or get back to my desktop.
I don't think loading the classes is a sustainable usage since
classfiles will not be available when incomplete files and is it not
inefficient and impossible to clean up.
For .jar's it's usable to look into ClassFileREader thouhgh.
/max
By now, java.lang.Class is used to load annotations.
To obtain Class objects, class loader is created for
user project. That way seems to be quite fast and reliable.
I have found that jdt uses
org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader
to load java model, and probably it provides all required information
about annotations, but that needs some more studies.
I think that for the time being we may use java.lang.Class-based
implementation to attend other urgent issues, and replace it
with ClassFileReader-based implementation later if time allows.
Slava Kabanovich
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
12:40 p.m.
New subject: Seam Scanner for class files
parse the source
I use class loader for .jar entries only.
Java sources (all java defined by user) are processed with
ASTParser as jdt does it, but ASTParser cannot process
binary entries.
What is APT, can it used for binary entries?
Slava Kabanovich
12:58 a.m.
New subject: Seam Scanner for class files
Viacheslav Kabanovich wrote:
> parse the source
I use class loader for .jar entries only.
Java sources (all java defined by user) are processed with
ASTParser as jdt does it, but ASTParser cannot process
binary entries.
ah ok - so its only in context of Jar you have issues.
Then yes, something like classfilereader or javassist should
be used to get these informations.
What is APT, can it used for binary entries?
APT = Annotation Processor Tool is a tool and api in java to
be able to process annotations in classes. Eclipse contains a
implementation that allows you to use the same api but I think
it only covers source code - not binary entries.
/max
11:15 a.m.
New subject: Seam Scanner for class files
I used APT in the jboss aop code. If you want to look at it I can direct
you to the svn location and package.
- Rob Stryker
Max Rydahl Andersen wrote:
> JDT does not include annotations into java model.
true, but that is why you use something like APT does and reads the
annotations. e.g. use the compilation participant and parse the source
and you can visit the nodes. I did that in my initial prototype,
unfortunatly i don't have the code on my laptop. I'll post it when I
find it or get back to my desktop.
I don't think loading the classes is a sustainable usage since
classfiles will not be available when incomplete files and is it not
inefficient and impossible to clean up.
For .jar's it's usable to look into ClassFileREader thouhgh.
/max
> By now, java.lang.Class is used to load annotations.
> To obtain Class objects, class loader is created for
> user project. That way seems to be quite fast and reliable.
>
> I have found that jdt uses
> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader
> to load java model, and probably it provides all required information
> about annotations, but that needs some more studies.
>
> I think that for the time being we may use java.lang.Class-based
> implementation to attend other urgent issues, and replace it
> with ClassFileReader-based implementation later if time allows.
>
> Slava Kabanovich
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
1:19 a.m.
New subject: Seam Scanner for class files
Eclipse APT ?!
How did you work around the issues of having the user register the APT
processing etc ? The need for that was the main reason I moved to the
"lower" level API which did not require special setup.
/max
I used APT in the jboss aop code. If you want to look at it I can
direct
you to the svn location and package.
- Rob Stryker
Max Rydahl Andersen wrote:
>
>> JDT does not include annotations into java model.
>
> true, but that is why you use something like APT does and reads the
> annotations. e.g. use the compilation participant and parse the source
> and you can visit the nodes. I did that in my initial prototype,
> unfortunatly i don't have the code on my laptop. I'll post it when I
> find it or get back to my desktop.
>
> I don't think loading the classes is a sustainable usage since
> classfiles will not be available when incomplete files and is it not
> inefficient and impossible to clean up.
>
> For .jar's it's usable to look into ClassFileREader thouhgh.
>
> /max
>
>
>> By now, java.lang.Class is used to load annotations.
>> To obtain Class objects, class loader is created for
>> user project. That way seems to be quite fast and reliable.
>>
>> I have found that jdt uses
>> org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader
>> to load java model, and probably it provides all required information
>> about annotations, but that needs some more studies.
>>
>> I think that for the time being we may use java.lang.Class-based
>> implementation to attend other urgent issues, and replace it
>> with ClassFileReader-based implementation later if time allows.
>>
>> Slava Kabanovich
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
6372
days inactive
6382
days old
jbosstools-dev@lists.jboss.org
11 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
Rob Stryker -
Viacheslav Kabanovich