Eclipse Community Forums: Visual Editor (VE) » Debugging Java beans in Visual Editor

Help

Home

Home » Archived » Visual Editor (VE) » Debugging Java beans in Visual Editor

Show: Today's Messages :: Show Polls :: Message Navigator

Debugging Java beans in Visual Editor [message #8115]

Thu, 04 December 2003 11:02

Miguel Tato

Messages: 18
Registered: July 2009

Junior Member

Hi everyone,

I am trying to add components in the visual palette. After testing the
examples that comes with the plugin, I need to be able to debug them like
any other plugins within the PDE.

There is a document from the Help that comes after installing the Visual
Editor plugin called "Debuggin Java beans", but I might be doing something
wrong.

I understand that this is something some of you are working with.

Please help,

Miguel Tato

Report message to a moderator

Re: Debugging Java beans in Visual Editor [message #8308 is a reply to message #8115]

Thu, 04 December 2003 18:50

Joe Winchester

Messages: 496
Registered: July 2009

Senior Member

--------------44ED2119E238C0AE6B933006
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Miguel,

> I am trying to add components in the visual palette. After testing the
> examples that comes with the plugin, I need to be able to debug them like
> any other plugins within the PDE.

The trick is that there are two JVMs involved - the one that is used by the
workbench and the one used by the target VM. When you do Debug As=>Runtime
Workbench this is how you launch Eclipse in debug mode so you debug the IDE
VM.

> There is a document from the Help that comes after installing the Visual
> Editor plugin called "Debuggin Java beans", but I might be doing something
> wrong.

Use the menu option Run=>Run and select the Run-time workbench configuration.
Select the Tracing tab, select the checkbox "Enable tracing". In the list of
plugins find the entry for "org.eclipse.jem.proxy". Select this and you
you'll see a table of property values. Select remote/debug/debugvm and enable
this.

What happens now when you launch the configuration (in either Run or Debug -
it doesn't matter as this affects the IDE JVM) is that each time the Visual
Editor starts a target VM you'll get prompted for whether you want to launch
it in debug mode or not. If you do then it will be started with an -Xdebug
option and you'll be given the port number in the next dialog.

Now go back to your development workbench (the one you launched the
configuration from) and select Debug=>Debug and create a new configuration for
"Remote Java Applicatoin". What you're doing is creating a debuggee that will
attach using a socket connector to the JVM started by the visual editor. The
Remote Java Application configuration has the host name (which is localhost
although there's nothing to stop you doing this across machines) and the port
name which you fill in to the one given by the dialog. It should switch to
debug perspective and you'll see a Process for the JVM you've attached to. Go
back to the dialog with the port number on it and press OK and everything will
carry on as normal. The difference is that the JVM is in debug mode and
you're attached to it. You can add breakpoints, catch exceptions, etc... as
you would for any other debug session.

One twist is that the Visual Editor start a JVM for each editor you open, and
also one per-project. The per-project one is used for BeanInfo introspection,
so when you get the dialog asking whether you want to start the arget JVM in
debug mode it'll be first a) the VE you open b) the project (because it will
almost immediately begin introspection and then subsequent ones will be for
every other VE you open. The b) dialog won't include the name of the .java
file you open so you will be able to tell it apart. Sometimes this JVM (or
even the ones for each editor) might get deliberately dropped and re-created
by the visual editor when it thinks a class has changed shape or the build
path is modified, and in these circumstances it will re-ask whether to debug
it nor and you go round the houses again.

The second twist is that you will need the "Remote Java Application"
configuration to be able to see your source code to do stepping and that kind
of stuff. The best way for this is to create a project in the IDE that
references all other ones and also has imported the source of the JavaBeans
you are debugging, and then specify this project name on the configuration
dialog.

Hope this helps,

Joe Winchester

--------------44ED2119E238C0AE6B933006
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Miguel,
<blockquote TYPE=CITE>I am trying to add components in the visual palette.
After testing the
<br>examples that comes with the plugin, I need to be able to debug them
like
<br>any other plugins within the PDE.</blockquote>
The trick is that there are two JVMs involved - the one that is used by
the workbench and the one used by the target VM.  When you do Debug
As=>Runtime Workbench this is how you launch Eclipse in debug mode so you
debug the IDE VM.
<blockquote TYPE=CITE>There is a document from the Help that comes after
installing the Visual
<br>Editor plugin called "Debuggin Java beans", but I might be doing something
<br>wrong.</blockquote>
Use the menu option Run=>Run and select the Run-time workbench configuration. 
Select the Tracing tab, select the checkbox "Enable tracing". In the list
of plugins find the entry for "org.eclipse.jem.proxy".  Select this
and you you'll see a table of property values.  Select remote/debug/debugvm
and enable this.
<p>What happens now when you launch the configuration (in either Run or
Debug - it doesn't matter as this affects the IDE JVM) is that each time
the Visual Editor starts a target VM you'll get prompted for whether you
want to launch it in debug mode or not.   If you do then it will
be started with an -Xdebug option and you'll be given the port number in
the next dialog.
<p>Now go back to your development workbench (the one you launched the
configuration from) and select Debug=>Debug and create a new configuration
for "Remote Java Applicatoin".  What you're doing is creating a debuggee
that will attach using a socket connector to the JVM started by the visual
editor.  The Remote Java Application configuration has the host name
(which is localhost although there's nothing to stop you doing this across
machines) and the port name which you fill in to the one given by the dialog. 
It should switch to debug perspective and you'll see a Process for the
JVM you've attached to.  Go back to the dialog with the port number
on it and press OK and everything will carry on as normal.  The difference
is that the JVM is in debug mode and you're attached to it.  You can
add breakpoints, catch exceptions, etc... as you would for any other debug
session.
<p>One twist is that the Visual Editor start a JVM for each editor you
open, and also one per-project.  The per-project one is used for BeanInfo
introspection, so when you get the dialog asking whether you want to start
the <tt>arget </tt>JVM in debug mode it'll be first a) the VE you open
b) the project (because it will almost immediately begin introspection
and then subsequent ones will be for every other VE you open.  The
b) dialog won't include the name of the .java file you open so you will
be able to tell it apart.  Sometimes this JVM (or even the ones for
each editor) might get deliberately dropped and re-created by the visual
editor when it thinks a class has changed shape or the build path is modified,
and in these circumstances it will re-ask whether to debug it nor and you
go round the houses again.
<p>The second twist is that you will need the "Remote Java Application"
configuration to be able to see your source code to do stepping and that
kind of stuff.  The best way for this is to create a project in the
IDE that references all other ones and also has imported the source of
the JavaBeans you are debugging, and then specify this project name on
the configuration dialog.
<p>Hope this helps,
<p>Joe Winchester</html>

--------------44ED2119E238C0AE6B933006--

Report message to a moderator

Re: Debugging Java beans in Visual Editor [message #9103 is a reply to message #8308]

Mon, 08 December 2003 23:54

Eclipse User

Originally posted by: migueli72.yahoo.com

This is a multi-part message in MIME format.

------=_NextPart_000_0058_01C3BDEE.F511DAC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It worked!

Thanks Joe
"Joe Winchester" <winchest@uk.ibm.com> wrote in message =
news:3FCF8204.C6F6F050@uk.ibm.com...
Hi Miguel,=20
I am trying to add components in the visual palette. After testing =
the=20
examples that comes with the plugin, I need to be able to debug them =
like=20
any other plugins within the PDE.
The trick is that there are two JVMs involved - the one that is used =
by the workbench and the one used by the target VM. When you do Debug =
As=3D>Runtime Workbench this is how you launch Eclipse in debug mode so =
you debug the IDE VM.=20
There is a document from the Help that comes after installing the =
Visual=20
Editor plugin called "Debuggin Java beans", but I might be doing =
something=20
wrong.
Use the menu option Run=3D>Run and select the Run-time workbench =
configuration. Select the Tracing tab, select the checkbox "Enable =
tracing". In the list of plugins find the entry for =
"org.eclipse.jem.proxy". Select this and you you'll see a table of =
property values. Select remote/debug/debugvm and enable this.=20
What happens now when you launch the configuration (in either Run or =
Debug - it doesn't matter as this affects the IDE JVM) is that each time =
the Visual Editor starts a target VM you'll get prompted for whether you =
want to launch it in debug mode or not. If you do then it will be =
started with an -Xdebug option and you'll be given the port number in =
the next dialog.=20

Now go back to your development workbench (the one you launched the =
configuration from) and select Debug=3D>Debug and create a new =
configuration for "Remote Java Applicatoin". What you're doing is =
creating a debuggee that will attach using a socket connector to the JVM =
started by the visual editor. The Remote Java Application configuration =
has the host name (which is localhost although there's nothing to stop =
you doing this across machines) and the port name which you fill in to =
the one given by the dialog. It should switch to debug perspective and =
you'll see a Process for the JVM you've attached to. Go back to the =
dialog with the port number on it and press OK and everything will carry =
on as normal. The difference is that the JVM is in debug mode and =
you're attached to it. You can add breakpoints, catch exceptions, =
etc... as you would for any other debug session.=20

One twist is that the Visual Editor start a JVM for each editor you =
open, and also one per-project. The per-project one is used for =
BeanInfo introspection, so when you get the dialog asking whether you =
want to start the arget JVM in debug mode it'll be first a) the VE you =
open b) the project (because it will almost immediately begin =
introspection and then subsequent ones will be for every other VE you =
open. The b) dialog won't include the name of the .java file you open =
so you will be able to tell it apart. Sometimes this JVM (or even the =
ones for each editor) might get deliberately dropped and re-created by =
the visual editor when it thinks a class has changed shape or the build =
path is modified, and in these circumstances it will re-ask whether to =
debug it nor and you go round the houses again.=20

The second twist is that you will need the "Remote Java Application" =
configuration to be able to see your source code to do stepping and that =
kind of stuff. The best way for this is to create a project in the IDE =
that references all other ones and also has imported the source of the =
JavaBeans you are debugging, and then specify this project name on the =
configuration dialog.=20

Hope this helps,=20

Joe Winchester=20

------=_NextPart_000_0058_01C3BDEE.F511DAC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>It worked!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks Joe</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Joe Winchester" <<A=20
href=3D"mailto:winchest@uk.ibm.com">winchest@uk.ibm.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:3FCF8204.C6F6F050@uk.ibm.com">news:3FCF8204.C6F6F050@uk.ibm.=
com</A>...</DIV>Hi=20
Miguel,=20
<BLOCKQUOTE TYPE=3D"CITE">I am trying to add components in the visual =
palette.=20
After testing the <BR>examples that comes with the plugin, I need to =
be able=20
to debug them like <BR>any other plugins within the =
PDE.</BLOCKQUOTE>The trick=20
is that there are two JVMs involved - the one that is used by the =
workbench=20
and the one used by the target VM.  When you do Debug =
As=3D>Runtime=20
Workbench this is how you launch Eclipse in debug mode so you debug =
the IDE=20
VM.=20
<BLOCKQUOTE TYPE=3D"CITE">There is a document from the Help that comes =
after=20
installing the Visual <BR>Editor plugin called "Debuggin Java =
beans", but I=20
might be doing something <BR>wrong.</BLOCKQUOTE>Use the menu option=20
Run=3D>Run and select the Run-time workbench configuration.  =
Select the=20
Tracing tab, select the checkbox "Enable tracing". In the list of =
plugins find=20
the entry for "org.eclipse.jem.proxy".  Select this and you =
you'll see a=20
table of property values.  Select remote/debug/debugvm and enable =
this.=20
<P>What happens now when you launch the configuration (in either Run =
or Debug=20
- it doesn't matter as this affects the IDE JVM) is that each time the =
Visual=20
Editor starts a target VM you'll get prompted for whether you want to =
launch=20
it in debug mode or not.   If you do then it will be started =
with an=20
-Xdebug option and you'll be given the port number in the next dialog. =

<P>Now go back to your development workbench (the one you launched the =

configuration from) and select Debug=3D>Debug and create a new =
configuration=20
for "Remote Java Applicatoin".  What you're doing is creating a =
debuggee=20
that will attach using a socket connector to the JVM started by the =
visual=20
editor.  The Remote Java Application configuration has the host =
name=20
(which is localhost although there's nothing to stop you doing this =
across=20
machines) and the port name which you fill in to the one given by the=20
dialog.  It should switch to debug perspective and you'll see a =
Process=20
for the JVM you've attached to.  Go back to the dialog with the =
port=20
number on it and press OK and everything will carry on as =
normal.  The=20
difference is that the JVM is in debug mode and you're attached to =
it. =20
You can add breakpoints, catch exceptions, etc... as you would for any =
other=20
debug session.=20
<P>One twist is that the Visual Editor start a JVM for each editor you =
open,=20
and also one per-project.  The per-project one is used for =
BeanInfo=20
introspection, so when you get the dialog asking whether you want to =
start the=20
<TT>arget </TT>JVM in debug mode it'll be first a) the VE you open b) =
the=20
project (because it will almost immediately begin introspection and =
then=20
subsequent ones will be for every other VE you open.  The b) =
dialog won't=20
include the name of the .java file you open so you will be able to =
tell it=20
apart.  Sometimes this JVM (or even the ones for each editor) =
might get=20
deliberately dropped and re-created by the visual editor when it =
thinks a=20
class has changed shape or the build path is modified, and in these=20
circumstances it will re-ask whether to debug it nor and you go round =
the=20
houses again.=20
<P>The second twist is that you will need the "Remote Java =
Application"=20
configuration to be able to see your source code to do stepping and =
that kind=20
of stuff.  The best way for this is to create a project in the =
IDE that=20
references all other ones and also has imported the source of the =
JavaBeans=20
you are debugging, and then specify this project name on the =
configuration=20
dialog.=20
<P>Hope this helps,=20
<P>Joe Winchester </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0058_01C3BDEE.F511DAC0--

Report message to a moderator

Re: Debugging Java beans in Visual Editor [message #572116 is a reply to message #8115]

Thu, 04 December 2003 18:50

Joe Winchester

Messages: 496
Registered: July 2009

Senior Member

Report message to a moderator

Re: Debugging Java beans in Visual Editor [message #573002 is a reply to message #8308]

Mon, 08 December 2003 23:54

Miguel Tato

Messages: 18
Registered: July 2009

Junior Member

This is a multi-part message in MIME format.

------=_NextPart_000_0058_01C3BDEE.F511DAC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It worked!

Thanks Joe
"Joe Winchester" <winchest@uk.ibm.com> wrote in message =
news:3FCF8204.C6F6F050@uk.ibm.com...
Hi Miguel,=20
I am trying to add components in the visual palette. After testing =
the=20
examples that comes with the plugin, I need to be able to debug them =
like=20
any other plugins within the PDE.
The trick is that there are two JVMs involved - the one that is used =
by the workbench and the one used by the target VM. When you do Debug =
As=3D>Runtime Workbench this is how you launch Eclipse in debug mode so =
you debug the IDE VM.=20
There is a document from the Help that comes after installing the =
Visual=20
Editor plugin called "Debuggin Java beans", but I might be doing =
something=20
wrong.
Use the menu option Run=3D>Run and select the Run-time workbench =
configuration. Select the Tracing tab, select the checkbox "Enable =
tracing". In the list of plugins find the entry for =
"org.eclipse.jem.proxy". Select this and you you'll see a table of =
property values. Select remote/debug/debugvm and enable this.=20
What happens now when you launch the configuration (in either Run or =
Debug - it doesn't matter as this affects the IDE JVM) is that each time =
the Visual Editor starts a target VM you'll get prompted for whether you =
want to launch it in debug mode or not. If you do then it will be =
started with an -Xdebug option and you'll be given the port number in =
the next dialog.=20

Now go back to your development workbench (the one you launched the =
configuration from) and select Debug=3D>Debug and create a new =
configuration for "Remote Java Applicatoin". What you're doing is =
creating a debuggee that will attach using a socket connector to the JVM =
started by the visual editor. The Remote Java Application configuration =
has the host name (which is localhost although there's nothing to stop =
you doing this across machines) and the port name which you fill in to =
the one given by the dialog. It should switch to debug perspective and =
you'll see a Process for the JVM you've attached to. Go back to the =
dialog with the port number on it and press OK and everything will carry =
on as normal. The difference is that the JVM is in debug mode and =
you're attached to it. You can add breakpoints, catch exceptions, =
etc... as you would for any other debug session.=20

One twist is that the Visual Editor start a JVM for each editor you =
open, and also one per-project. The per-project one is used for =
BeanInfo introspection, so when you get the dialog asking whether you =
want to start the arget JVM in debug mode it'll be first a) the VE you =
open b) the project (because it will almost immediately begin =
introspection and then subsequent ones will be for every other VE you =
open. The b) dialog won't include the name of the .java file you open =
so you will be able to tell it apart. Sometimes this JVM (or even the =
ones for each editor) might get deliberately dropped and re-created by =
the visual editor when it thinks a class has changed shape or the build =
path is modified, and in these circumstances it will re-ask whether to =
debug it nor and you go round the houses again.=20

The second twist is that you will need the "Remote Java Application" =
configuration to be able to see your source code to do stepping and that =
kind of stuff. The best way for this is to create a project in the IDE =
that references all other ones and also has imported the source of the =
JavaBeans you are debugging, and then specify this project name on the =
configuration dialog.=20

Hope this helps,=20

Joe Winchester=20

------=_NextPart_000_0058_01C3BDEE.F511DAC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2734.1600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>It worked!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks Joe</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Joe Winchester" <<A=20
href=3D"mailto:winchest@uk.ibm.com">winchest@uk.ibm.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:3FCF8204.C6F6F050@uk.ibm.com">news:3FCF8204.C6F6F050@uk.ibm.=
com</A>...</DIV>Hi=20
Miguel,=20
<BLOCKQUOTE TYPE=3D"CITE">I am trying to add components in the visual =
palette.=20
After testing the <BR>examples that comes with the plugin, I need to =
be able=20
to debug them like <BR>any other plugins within the =
PDE.</BLOCKQUOTE>The trick=20
is that there are two JVMs involved - the one that is used by the =
workbench=20
and the one used by the target VM.  When you do Debug =
As=3D>Runtime=20
Workbench this is how you launch Eclipse in debug mode so you debug =
the IDE=20
VM.=20
<BLOCKQUOTE TYPE=3D"CITE">There is a document from the Help that comes =
after=20
installing the Visual <BR>Editor plugin called "Debuggin Java =
beans", but I=20
might be doing something <BR>wrong.</BLOCKQUOTE>Use the menu option=20
Run=3D>Run and select the Run-time workbench configuration.  =
Select the=20
Tracing tab, select the checkbox "Enable tracing". In the list of =
plugins find=20
the entry for "org.eclipse.jem.proxy".  Select this and you =
you'll see a=20
table of property values.  Select remote/debug/debugvm and enable =
this.=20
<P>What happens now when you launch the configuration (in either Run =
or Debug=20
- it doesn't matter as this affects the IDE JVM) is that each time the =
Visual=20
Editor starts a target VM you'll get prompted for whether you want to =
launch=20
it in debug mode or not.   If you do then it will be started =
with an=20
-Xdebug option and you'll be given the port number in the next dialog. =

<P>Now go back to your development workbench (the one you launched the =

configuration from) and select Debug=3D>Debug and create a new =
configuration=20
for "Remote Java Applicatoin".  What you're doing is creating a =
debuggee=20
that will attach using a socket connector to the JVM started by the =
visual=20
editor.  The Remote Java Application configuration has the host =
name=20
(which is localhost although there's nothing to stop you doing this =
across=20
machines) and the port name which you fill in to the one given by the=20
dialog.  It should switch to debug perspective and you'll see a =
Process=20
for the JVM you've attached to.  Go back to the dialog with the =
port=20
number on it and press OK and everything will carry on as =
normal.  The=20
difference is that the JVM is in debug mode and you're attached to =
it. =20
You can add breakpoints, catch exceptions, etc... as you would for any =
other=20
debug session.=20
<P>One twist is that the Visual Editor start a JVM for each editor you =
open,=20
and also one per-project.  The per-project one is used for =
BeanInfo=20
introspection, so when you get the dialog asking whether you want to =
start the=20
<TT>arget </TT>JVM in debug mode it'll be first a) the VE you open b) =
the=20
project (because it will almost immediately begin introspection and =
then=20
subsequent ones will be for every other VE you open.  The b) =
dialog won't=20
include the name of the .java file you open so you will be able to =
tell it=20
apart.  Sometimes this JVM (or even the ones for each editor) =
might get=20
deliberately dropped and re-created by the visual editor when it =
thinks a=20
class has changed shape or the build path is modified, and in these=20
circumstances it will re-ask whether to debug it nor and you go round =
the=20
houses again.=20
<P>The second twist is that you will need the "Remote Java =
Application"=20
configuration to be able to see your source code to do stepping and =
that kind=20
of stuff.  The best way for this is to create a project in the =
IDE that=20
references all other ones and also has imported the source of the =
JavaBeans=20
you are debugging, and then specify this project name on the =
configuration=20
dialog.=20
<P>Hope this helps,=20
<P>Joe Winchester </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0058_01C3BDEE.F511DAC0--

Report message to a moderator

Previous Topic:	VE Release 0.5.0 is final and available.
Next Topic:	VE and SWT

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Feb 05 13:02:12 GMT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter