Aws backend code debugging - eclipse

I deployed my backend code(used framework is drop-wizard) in the form of jar file on AWS(Amazon Web service) server. I want to know is it possible to debug that jar file(jar file deployed on the AWS server) using eclipse on my local pc?? If yes than please display the way of how to do it??
Looking for a good response
Thanks

First, you need to start your application with remote debugging
enabled. With dropwizard, you are typically starting the application
on a server with:
java -jar myapp-0.0.1-SNAPSHOT.jar
Change this to:
java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar myapp-0.0.1-SNAPSHOT.jar
This sets up Java to listen for remote debugging sessions on port
9999. Make sure you choose a port that's not blocked by firewalls or
your AWS security configuration.
Next, you have to configure Eclipse to connect to the remote
application for debugging. In Eclipse, right click on the project and
select Debug, Debug Configuration. Create a new configuration of
Remote Java Application. Set the host to your AWS server and the port
to 9999, as above.
Now you should be able to set a breakpoint in your code and start a
debug session on the remote server.

Related

Start Websphere Liberty in Debug mode and connect via Eclipse

I am searching for a way to start the Websphere Liberty profile in debug mode from the command line? I want to be able to start Liberty, so that it is listening for debug connections on a specific port. Then I would like to connect to Liberty from Eclipse, so that I can step through and debug the server code running in Liberty.
I've tried integrating Liberty into Eclipse and using the Eclipse 'Servers' view. This works great and I can start and stop Liberty using debug mode. Unfortunately, this method does not satisfy my use case because the build process uses tools external to Eclipse.
Essentially, I need a way to do this via the command line.
I tried creating a jvm.options file for Liberty and starting it, but I still can't connect to the port I specified. I'm sure I'm doing something wrong, but thus far I haven't figured it out.
This page has some info on jvm.options
The Administering the Liberty profile from the command prompt page describes how to do this:
[bin]$ export WLP_DEBUG_ADDRESS=7778
[bin]$ ./server debug
Listening for transport dt_socket at address: 7778
You can then connect from Eclipse using Remote Debugging.

Remote Tomcat Server Configuration hangs the server startup when parameter suspend=y used

It would be great if someone can help me on this:
I configured a tomcat server for doing remote debugging using eclipse:
I used the gui for tomcat7
If I run tomcat with the command
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n it works fine but
If I put suspend=y in the above command tomcat sert hangs in starting state and does not stop at all even after 2-3 hours.
When using suspend=y, the JVM remains suspended until a debug client connects.
To connect to the suspended Tomcat instance, you can create a new Eclipse Debug Configuration via Run->Debug Configurations. Then choose Remote Java Application. On the configuration panel, specify the host and port e.g. 8000 to connect. Finally, press Debug. This will attempt to connect to your suspended Tomcat instance. Once, the connection is made you can step through the code. (Of course, you must load that code into the Eclipse workspace)

Debug Struts Action Classes

My application runs on a remote server.
I use tomcat to deploy the web based part of my application.
The flow is Action classes calls the remote classes using RMI.
I am using Eclipse and When I browse a page, am able to debug the remote java classess, But I need to debug Action classes also as it also contains more logic.
How will I do it, Please help, Thanks in advance.
Regards,
Sridevi
Either launch Tomcat in debug mode from Eclipse, or launch tomcat with remote debug options, and attach a remote debug session from Eclipse to this tomcat server (in a similar way as you're probably doing for the remote RMI server).
See http://wiki.apache.org/tomcat/HowTo#How_do_I_debug_a_Tomcat_application.3F for how to start tomcat in remote debug mode:
set JPDA_ADDRESS=1044
set JPDA_TRANSPORT=dt_socket
catalina jpda start

How do you connect an eclipse to a WebSphere Application server hosted on remote server?

I am trying to debug a local code ( which is on my laptop) using eclipse, which I am trying to connect to the remotely hosted WAS( WebSphere Application server) and remotely hosted database.
To remotely connect to WAS, first, from the WebSphere Integrated Solutions Console:
Navigate to the application server's Debugging Service:
Servers > Server Types > WebSphere application servers > [serverName] > Debugging Service
Check the "Enable service at server startup" checkbox
Add/modify the "JVM debug port" if necessary (the port must not already be in use on the server)
Add/modify the "JVM debug arguments" if necessary (this may already appear by default):
-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777
Apply the changes, Save the new configuration, and Restart the application server
Then, from the Eclipse IDE:
Open the "Debug" dialog (e.g. Run > Debug Configurations...)
Right-click "Remote Java Application" and select "New"
Configure the Remote Java Application:
Name the debug configuration
Browse to select the project to debug (optional)
Use the "Standard (Socket Attach)" Connection Type
Specify the hostname of your WAS server
Specify the port number that was set in the WAS debug options
Click Apply
Click Debug
(These instructions are for WAS 7.0, but should be similar for other versions.)

Eclipse and GlassFish: remote deployment and debugging

I am currently using Eclipse to develop a fairly straight-forward Java EE dynamic web application. I have just been using Eclipse to deploy the web app to a GlassFish 3.1 server locally running on my dev machine for development and debugging purposes.
So far, so good. But now, I am looking into deploying the app to a remote GF server for further testing.
In Eclipse, I open the "Servers" tab and select the "New->Server" context menu. I enter the IP address of the remote server running GlassFish, but the "New Server" dialog won't let me proceed. Instead, it gives me the error message:
Remote Server is not secured: It
cannot be used remotely...
Some initial research suggests that remote deployment/debugging is currently not supported by Eclipse. Is that what Eclipse is trying to tell me with this weird error message? Surely "Remote deployment/debugging not supported" would be more apt. Am I overlooking something fundamental here?
Read http://blogs.oracle.com/quinn/entry/securing_adminstration_in_glassfish_server1
Access to remote servers can only be done if the server has been secured...
You want to make sure you have enabled secure administration. Generally you should do the following:
using ./asadmin change-admin-password command to set a password on the 'admin' user. By default there is none (so when it asks for your current admin password just hit Enter assuming you've never set one)
using ./asadmin start-domain to startup the default 'domain1'
using ./asadmin --host localhost --port 4848 enable-secure-admin will enable remote administration access (which you want) and tell Glassfish to start on the localhost at the default admin port 4848
finally use ./asadmin restart-domain to restart and apply those changes.
You should be able to now access the remote server and manage it via your Eclipse install. This works for Eclipse Luna and Glassfish4 open-source edition. Also note that you need to have a glassfish install on your Local development machine and point to that when it asks for the path to the Glassfish installation when setting up the server in Eclipse Wizard...despite the fact that you are connecting to a remote Glassfish instance. (See my SO post for more details/screenshots).
I am adding this because the current accepted answer only points to a link which is typically frowned upon here on SO since links have a tendency to go dead unexpectedly.