Home » Eclipse Projects » Equinox » Instructions for debugging the servletbridge using WST and the PDE (long)
| Instructions for debugging the servletbridge using WST and the PDE (long) [message #95708] |
Wed, 22 August 2007 13:23  |
Eclipse User |
|
|
|
After considerable trial and error, I was able to debug my application
that uses the servlet bridge with the PDE. Note that maybe debugging is
too strong, as I could not actually set breakpoints nor access any of my
application's code in the debugger (since the debugger could not see
those classes), but I could debug the outer servlet and use printlns()
to debug the rest (which is fine with me). The point is I could quickly
launch my (large) application from the debugger in this manner. Without
this it is only possible to launch when deployed to a war file using the
headless build scripts (which take a long time).
This provides my notes about how to debug a servletbridge started
application. The more interesting part is the section on Debugging. I
would be interested in any feedback anyone has to make this process more
simple, and would be happy to file an enhancement request somewhere to
encourge the necessary changes to make this more automatic.
Thanks,
Francis
--------------------------
Background
The purpose of the servlet is to be deployable in an application server
like Tomcat. This allows maps to be served as a REST web service. See
the runtime documentation for further details on how this works.
In order to do this, we use the Equinox servletbridge technology
(bundled as part of the standard Eclipse 3.3 platform) which provides
a BridgeServlet (we subclass this with RuntimeServletBridge, which is in
this plugin). RuntimeServletBridge is registered with the app server
and it starts the Eclipse environment and sends requests to the actual
RuntimeServlet (found in the com.oaklandsw.transform.runtime plugin)
which actually does the work.
The RuntimeServletBridge can get information from the app server
environment and save it statically which is picked up by the
RuntimeServlet when the request is executed.
There are of course issues with the classloaders to make this all
happen. It is important that the classloader of the actual Eclipse
runtime see the same RuntimeServletBridge, servletbridge, and
javax.servlet.* classes as those visible by the app server. If this
does not happen, the RuntimeServlet will not see the information
recorded by the RuntimeServletBridge (because it will be looking at its
own local copy of the servletbridge) and will therefore not start the
transform runtime. This manifests in a NPE in the RuntimeServlet when
processing a request.
To make this linkage with the classloaders, the BridgeServlet generates
a jar file that contains the linkage information. This is done when it
starts up and deploys the Eclipse environment into the web app work
area. By default it puts the servletbridge package and the
javax.servlet.* packages. Thanks to the extendedFrameworkExports
parameter in the web.xml file, it adds the
com.oaklandsw.transform.runtime.servlet package. It is important that
this package not be renamed unless the web.xml file and the scripts (see
com.oaklandsw.transform.build/scripts/customTargets.xml) are updated.
Deployment
In the [application] osdm.war file, the entire runtime installation set
of features/plugins is provided. The customTargets.xml script does this.
The web.xml file has the parameter that creates the OSGI console
commented out. This is because in a deployment environment, it will
loop forever trying to read the console (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=192361).
However, when testing (see below), the console needs to be enabled).
Debugging
In order to debug this, it is convenient to use the Eclipse WST support
which allows debugging in an app server. Currently, the runtime.servlet
project is setup to be debugged using a Tomcat 6.0 server.
Since it is not easy and fast to copy all of the plugins (Eclipse and
ours) to the webapp directly, testing is done by hacks with the PDE
support. These hacks need to be updated when upgrading to a new version
of Eclipse. Hopefully at some point, the Eclipse PDE will directly
support using the WST with the servletbridge. Until then here is what
to do:
1) provide a platform.xml file. This is located in the servlet plugin
at
WebContent/WEB-INF/eclipse/configuration/org.eclipse.update/ platform.xml.
This is not used for deployment at all. This file tells the
org.eclipse.update how to find any of the required plugins (as if they
were actually present in the plugins directory). The plugins are
identified in 3 parts:
1) the plugins being developed. Here it is sufficient to point to
the project directories of the required plugins.
2) the generated plugin (created above by the servletbridge). This
points to a local copy of the
org.eclipse.equinox.servletbridge.extensionbundle_1.0.0.jar file.
This copy is checked in and generally will not need to change. If you
need to get a new one of these, execute the servlet and copy this file
from the following directory:
[workspaceroot]/.metadata/.plugins/org.eclipse.wst.server.co re/tmp0/work/Catalina/localhost/osdm/eclipse/plugins
(unfortunately, we don't seem to have the ability of setting the
platform.xml file to refer to this generated file directly, as the
generated file does not seem to be present when required by the plugin
loading mechanism that uses platform.xml)
3) The base plugins, this is simply a matter of referring to all
deployed plugins using like this:
<site enabled="true"
policy="USER-EXCLUDE" updateable="true"
url="platform:/base/">
</site>
To get the platform.xml file, run an application that requires the
same plugins (the transform designer for example), and look in the
following location:
[workspaceroot]/.metadata/.plugins/org.eclipse.pde.core/[run
config]/org.eclipse.update/platform.xml
Then copy only the first part of this platform.xml file (the part
that refers to the plugins being developed) into the platform.xml file
used for development.
2) provide the dev.properties. This is located in the servlet plugin at
WebContent/WEB-INF/eclipse/dev.properties. This needs to be updated if
any new application plugins are added. You can get the file (after
running an application requiring all of the same plugins) here:
[workspaceroot]/.metadata/.plugins/org.eclipse.pde.core/[run
config]/dev.properties
3) provide the launch.ini file. This is located in the servlet plugin
at WebContent/WEB-INF/eclipse/launch.ini. Note in some Equinox examples
and documentation you will see some of these properties defined in the
configuration/config.ini file. We don't use that file and define all
of the properties in launch.ini.
The checked-in launch.ini file is for development purposes. A
launch.ini.prod file is for deployment (the script that builds the war
file renames this to launch.ini for the deployed kit). These files
differ in the following ways:
1) The development launch.ini does not include the application plugin
(com.oaklandsw.transform.runtime) in the osgi.bundles property. This is
because this plugin is not available initially (it seems to depend on
the activities of the org.eclipse.update plugin to get setup). In the
production version, the application plugin is specified because all of
the plugins are directly present in the same directory.
2) The development launch.ini includes two extra properties 1)
osgi.dev which defines the location of the (checked in) dev.properties, and
2) osgi.install.area which defines the location of the target platform.
4) Change the web.xml file to turn on the console option (see above in
deployment)
5) *Important* when restarting the Tomcat server after changing the
platform.xml file, it's critical that you *both* do a "Clean...", and
a "Clean Tomcat Work Directory...", and then a "Republish". If there is
any doubt, do something to put an obvious error in your file (like
change an element name to make the XML not parse) and try it until you
get the expected error when running to make sure you have done the
correct incantations to reset everything.
|
|
|
| Re: Instructions for debugging the servletbridge using WST and the PDE (long) [message #95816 is a reply to message #95708] |
Thu, 23 August 2007 10:54  |
| Eclipse User |
|
|
|
Good write up.
I had one question as I'm curious why you're not able to debug your bundles
fully.
How are you connecting to tomcat? I normally just use "Remote Java
Application" and then add whatever bundle projects as "Java Projects" and
then can set break points etc.
e.g. I start Tomcat with "call "%EXECUTABLE%" jpda start %CMD_LINE_ARGS%" as
one of the last lines in my startup script.
.... and then connect using regular Eclipse remote debugging.
Are you saying that you can get this to work for a complete war file but
that it doesn't seem to work when use platform.xml and the logic in update
configurator?
-Simon
"Francis Upton" <francisu@ieee.org> wrote in message
news:fahre4$st7$1@build.eclipse.org...
> After considerable trial and error, I was able to debug my application
> that uses the servlet bridge with the PDE. Note that maybe debugging is
> too strong, as I could not actually set breakpoints nor access any of my
> application's code in the debugger (since the debugger could not see those
> classes), but I could debug the outer servlet and use printlns() to debug
> the rest (which is fine with me). The point is I could quickly launch my
> (large) application from the debugger in this manner. Without this it is
> only possible to launch when deployed to a war file using the headless
> build scripts (which take a long time).
>
> This provides my notes about how to debug a servletbridge started
> application. The more interesting part is the section on Debugging. I
> would be interested in any feedback anyone has to make this process more
> simple, and would be happy to file an enhancement request somewhere to
> encourge the necessary changes to make this more automatic.
>
> Thanks,
>
> Francis
>
> --------------------------
>
> Background
>
> The purpose of the servlet is to be deployable in an application server
> like Tomcat. This allows maps to be served as a REST web service. See the
> runtime documentation for further details on how this works.
>
> In order to do this, we use the Equinox servletbridge technology (bundled
> as part of the standard Eclipse 3.3 platform) which provides
> a BridgeServlet (we subclass this with RuntimeServletBridge, which is in
> this plugin). RuntimeServletBridge is registered with the app server and
> it starts the Eclipse environment and sends requests to the actual
> RuntimeServlet (found in the com.oaklandsw.transform.runtime plugin) which
> actually does the work.
>
> The RuntimeServletBridge can get information from the app server
> environment and save it statically which is picked up by the
> RuntimeServlet when the request is executed.
>
> There are of course issues with the classloaders to make this all happen.
> It is important that the classloader of the actual Eclipse runtime see the
> same RuntimeServletBridge, servletbridge, and javax.servlet.* classes as
> those visible by the app server. If this does not happen, the
> RuntimeServlet will not see the information recorded by the
> RuntimeServletBridge (because it will be looking at its own local copy of
> the servletbridge) and will therefore not start the transform runtime.
> This manifests in a NPE in the RuntimeServlet when processing a request.
>
> To make this linkage with the classloaders, the BridgeServlet generates
> a jar file that contains the linkage information. This is done when it
> starts up and deploys the Eclipse environment into the web app work area.
> By default it puts the servletbridge package and the javax.servlet.*
> packages. Thanks to the extendedFrameworkExports parameter in the web.xml
> file, it adds the com.oaklandsw.transform.runtime.servlet package. It is
> important that this package not be renamed unless the web.xml file and the
> scripts (see com.oaklandsw.transform.build/scripts/customTargets.xml) are
> updated.
>
> Deployment
>
> In the [application] osdm.war file, the entire runtime installation set of
> features/plugins is provided. The customTargets.xml script does this.
>
> The web.xml file has the parameter that creates the OSGI console commented
> out. This is because in a deployment environment, it will loop forever
> trying to read the console (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192361).
> However, when testing (see below), the console needs to be enabled).
>
>
> Debugging
>
> In order to debug this, it is convenient to use the Eclipse WST support
> which allows debugging in an app server. Currently, the runtime.servlet
> project is setup to be debugged using a Tomcat 6.0 server.
>
> Since it is not easy and fast to copy all of the plugins (Eclipse and
> ours) to the webapp directly, testing is done by hacks with the PDE
> support. These hacks need to be updated when upgrading to a new version of
> Eclipse. Hopefully at some point, the Eclipse PDE will directly support
> using the WST with the servletbridge. Until then here is what to do:
>
> 1) provide a platform.xml file. This is located in the servlet plugin at
> WebContent/WEB-INF/eclipse/configuration/org.eclipse.update/ platform.xml.
> This is not used for deployment at all. This file tells the
> org.eclipse.update how to find any of the required plugins (as if they
> were actually present in the plugins directory). The plugins are
> identified in 3 parts:
>
> 1) the plugins being developed. Here it is sufficient to point to the
> project directories of the required plugins.
> 2) the generated plugin (created above by the servletbridge). This
> points to a local copy of the
> org.eclipse.equinox.servletbridge.extensionbundle_1.0.0.jar file. This
> copy is checked in and generally will not need to change. If you need to
> get a new one of these, execute the servlet and copy this file from the
> following directory:
>
>
> [workspaceroot]/.metadata/.plugins/org.eclipse.wst.server.co re/tmp0/work/Catalina/localhost/osdm/eclipse/plugins
>
> (unfortunately, we don't seem to have the ability of setting the
> platform.xml file to refer to this generated file directly, as the
> generated file does not seem to be present when required by the plugin
> loading mechanism that uses platform.xml)
> 3) The base plugins, this is simply a matter of referring to all
> deployed plugins using like this:
> <site enabled="true"
> policy="USER-EXCLUDE" updateable="true"
> url="platform:/base/">
> </site>
>
> To get the platform.xml file, run an application that requires the same
> plugins (the transform designer for example), and look in the following
> location:
>
> [workspaceroot]/.metadata/.plugins/org.eclipse.pde.core/[run
> config]/org.eclipse.update/platform.xml
>
> Then copy only the first part of this platform.xml file (the part that
> refers to the plugins being developed) into the platform.xml file used for
> development.
>
> 2) provide the dev.properties. This is located in the servlet plugin at
> WebContent/WEB-INF/eclipse/dev.properties. This needs to be updated if
> any new application plugins are added. You can get the file (after
> running an application requiring all of the same plugins) here:
>
> [workspaceroot]/.metadata/.plugins/org.eclipse.pde.core/[run
> config]/dev.properties
>
> 3) provide the launch.ini file. This is located in the servlet plugin at
> WebContent/WEB-INF/eclipse/launch.ini. Note in some Equinox examples and
> documentation you will see some of these properties defined in the
> configuration/config.ini file. We don't use that file and define all
> of the properties in launch.ini.
>
> The checked-in launch.ini file is for development purposes. A
> launch.ini.prod file is for deployment (the script that builds the war
> file renames this to launch.ini for the deployed kit). These files differ
> in the following ways:
>
> 1) The development launch.ini does not include the application plugin
> (com.oaklandsw.transform.runtime) in the osgi.bundles property. This is
> because this plugin is not available initially (it seems to depend on the
> activities of the org.eclipse.update plugin to get setup). In the
> production version, the application plugin is specified because all of the
> plugins are directly present in the same directory.
> 2) The development launch.ini includes two extra properties 1) osgi.dev
> which defines the location of the (checked in) dev.properties, and
> 2) osgi.install.area which defines the location of the target platform.
>
> 4) Change the web.xml file to turn on the console option (see above in
> deployment)
>
> 5) *Important* when restarting the Tomcat server after changing the
> platform.xml file, it's critical that you *both* do a "Clean...", and
> a "Clean Tomcat Work Directory...", and then a "Republish". If there is
> any doubt, do something to put an obvious error in your file (like change
> an element name to make the XML not parse) and try it until you get the
> expected error when running to make sure you have done the correct
> incantations to reset everything.
>
>
|
|
|
Goto Forum:
Current Time: Wed Jun 25 13:57:40 EDT 2025
Powered by FUDForum. Page generated in 0.04691 seconds |
Home