[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Dltk-dev] Welcome Johan Compagner as a new technology.dltk Committer
|
ok - i'm following now.
i guess you have somewhat of a unique situation here because you are able to start the parent application from within eclipse. while it is annoying to have to suffer some kind of user interaction to start the session, i think both mechanisms will need to be supported in the end since there are probably people out there who will want to use the firefox plugin.
i believe that some of the rse implentation is supposed to handle some of this so 'remote' clients can appear as if they were local file systems and interpreters can run as if they were local to eclipse, but model breaks down for me in the embedded case because eclipse can not start the parent application the perl interpreter is embedded in. my situation is pretty much akin to an apache server running mod perl, so i have no choice but to rely on listening for an outgoing connection - yes it's annoying, but that's 100x better (for me) then having no debugger at all.
how are you handling source lookup right now? are you attempting to map the source back into the project workspace, or are you relying on the fact that dbgp will send back the source contents if requested (support for both currently exists, although there are issues associated with both when it comes to breakpoints that i'm working to resolve).
On Tue, Apr 22, 2008 at 2:46 PM, Johan Compagner <
jcompagner@xxxxxxxxx> wrote:
I can run a tomcat where ever i want and connect to it as often is as i want, thats just a matter how you connect to it.
For example that tomcat is waiting for you to connect is because of the debug string suspend=y (which is default to y)
this-Xrunjdwp:transport=dt_socket,server=y,address=8118,suspend=n
will not wait for you to connect to it with the debugger.
The problem is that the none remote launch just doesn't work for us.
We have an java application with a rhino script engine running inside of it. And we cant just start that java application everytime we want to debug a script
no that java applicaiton is started once and then the debugger just connects to it
That java application is just started with a parameter that it needs must hook up the rhino debugger in the Rhino engine.
That debugger just opens up a ServerSocket and just waits, so the java application runs fine and at the moment somebody wants to debug it
it makes a connection and then it debugs. Then it can terminate it again and the debugger in the engine is discarded, waiting for the next one.
So it is just different that what you do just starting an inteperter/script when the the eclipse debugger wants it to do.
We also dont just run scripts. We really hook up into a complete application with dozens or hundreds of scripts with functions
those are just exacuted/debugged when a user presses buttons or triggers events in the java application. So it is really an embedded thing not a stand alone thing.
And i definitly dont want the java application to be the trigger to the debugger. That is an horrible end user experience...
I really think things like komodo do it the wrong way around. Eclipse debugger is the trigger not the application that is just a slave.
And if you do it the other way around then everyhing is possible see java debugging. Because then you can de remote debugging or local debugging with the same thing
Because local just means that eclipse starts the java process, it knows on what port (because it gives that to the application jvm debug settings),
eclipse just waits a while for the java app to come up then connects to it and it goes on.
If it has to remote debug an existing app then it works the same way because eclipse still makes the connections but only skips the starting and you have to tell the port because eclipse didnt do that themself.
So you see then you are not limitted at all everything works, the other way around is just annoying because it cant work without user interactions and configuration on both sides....
johan
On Tue, Apr 22, 2008 at 8:25 PM, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
the last time i debugged a tomcat process (it's been a while now), i recall my having to start the server and then it sat around until i started the eclipse debugging session, which caused tomcat to startup and then allow the session to continue. i could disconnect from the session and tomcat would still be running, but there did not seem to be a way to reconnect without a restart.
i thought dbpg worked the opposite - the ide had to be told to listen for incoming debugger connections and then when it got one, start the debugging process. that's what the docs for komodo say to do, and i can't start debugging a remote perl script in eclipse unless the dbgp server is running, and the only way i know of to do that is to launch a remote debugging session to start the server and then start the script on the remote host.
if you're saying that eclipse needs to make an outbound connection to your process instead of the other way around, then it would seem to go against how all the other dbpg implementations work. check out the docs for the active state firefox plugin:
http://aspn.activestate.com/ASPN/docs/Komodo/4.3/debugjs.html
it says to put komodo in 'listen' mode (which would be the equivalent of launching a remote debug process) and then go into firefox and tell it to connect (which would be the equivalent of executing the script/whatever on the remote client).
On Tue, Apr 22, 2008 at 1:56 PM, Johan Compagner <
jcompagner@xxxxxxxxx> wrote:
It works just as remote java debugging.
I dont have a process that i kick of.. It is long running already. It could be even already long running before i start eclipse...
For example in java, if i remote debug a java tomcat.
Then i create a remote launch configuration where i fill in the host and the port to connect to
The tomcat is configured with to start a debugger alone. That debug doesnt make a connection to eclipse .. no eclipse makes a connection to the tomcat.
By the way even none remote launch configs works like that in java the debug process always starts a ServerSocket and then eclipse makes a connection to it.
Only the _javascript_ debug works the other way around that the to debug program connects back to eclipse..
johanOn Tue, Apr 22, 2008 at 6:10 PM, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
wait - do we, maybe i am confused...
if i debug a local perl process, kicking off the 'launch' starts the server listening for a connection and then when my program is run, it makes an outbound connection to the server and then it works. in the remote case, i kick off the 'remote' launch, which just sits and waits. then i head over to the remote host and kick off the perl process. as long as i've exported the proper environment variables, it connects and starts the debugging process.
are you saying it is the reverse for the _javascript_ engine?
i looked at the xpi plugin from the active state guys for this and it looks like it works the exact same way.
On Tue, Apr 22, 2008 at 12:00 PM, Johan Compagner <
jcompagner@xxxxxxxxx> wrote:
Ahh but then we work differently
you say "dbgp services to start listening to incoming connections"
But it is the other way. the dbgp services has to make a connection. The ServerSocket is there at the remote _javascript_ engine process not the dpgp service.
Because how do i tell the already running process that it has to connect to the dpgp services server socket and at which port??
look this is part of a new DbgpClient class (instead of DbpgServer class):
public class DbgpClient extends DbgpWorkingThread {
private final int port;
private final int clientTimeout;
private IDbgpServerListener listener;
private DbgpDebugingEngine dbgpDebugingEngine;
private DbgpSession session;
protected synchronized void workingCycle() throws Exception, IOException {
try {
if (listener != null) {
Socket client = new Socket("127.0.0.1",port); << see it opens a socket not waits for a socket.
client.setSoTimeout(clientTimeout);
try {
dbgpDebugingEngine = new DbgpDebugingEngine(client);
session = new DbgpSession(dbgpDebugingEngine);
listener.clientConnected(session);
}
catch (Exception e) {
DLTKDebugPlugin.log(e);
if (dbgpDebugingEngine != null)
dbgpDebugingEngine.requestTermination();
}
}
} catch (Exception e)
{
e.printStackTrace();
}
}
On Tue, Apr 22, 2008 at 5:49 PM, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
hrm - i didn't have to do any of that to get remote perl debugging up
and running. as soon as you spawn a remote launch configuration, that
should kick off the dbgp service to start listening for incoming
connections. as long as you set the 'idekey' property in the remote
launch config to be whatever you used on the remote side, it should just connect.
of course, i could be missing something, or perhaps there was some other change that has occurred as of late (the day job has been keeping me pretty busy, so i'm playing some catch-up with the recent set of changes) that i haven't accounted for yet.
On Tue, Apr 22, 2008 at 11:40 AM, Johan Compagner <
jcompagner@xxxxxxxxx> wrote:
No it works, only i have to handle disconnects and so on a bit more gracefull.
And launch configurations and other settings like port has to be better handed thats now pretty much hardcoded
But I remote debug a Rhino instance that is already running.
So instead of starting an instance i connect to it. I use the RemoteDebuggingEngineRunner that already is in the code base
public class ServoyDebuggableEngineFactory implements IInterpreterRunnerFactory
{
public ServoyDebuggableEngineFactory()
{
}
public IInterpreterRunner createRunner(IInterpreterInstall install)
{
return new RemoteDebuggingEngineRunner(install)
{
@Override
protected String getDebugPreferenceQualifier()
{
return "servoy";
}
};
}
}
But that didnt have any IDbgpService that it could use because the current one is purely there for starting a none remote one.
So what i did was created a class:
public class RemoteDbgpService implements IDbgpService,
IDbgpTerminationListener, IDbgpServerListener
that can connect to an instance.
So the RemoteDebuggingEngine does this:
protected IDbgpService getDbgpService()
{
return DLTKDebugPlugin.getDefault().getRemoteDbgpService();
}
And apart from some disconnect issues that i have to handle a bit better (but on the client side not the eclipse debugger)
and the ports/addresses configuration stuff it works for us.
johanOn Tue, Apr 22, 2008 at 5:32 PM, Jae Gangemi <
jgangemi@xxxxxxxxx> wrote:
i'd like to hear about your remote debugging work - what do you have working at this point in time? what doesn't work for you?
On Tue, Apr 22, 2008 at 11:30 AM, Johan Compagner <
jcompagner@xxxxxxxxx> wrote:
Hi guys (and girls if there are any..;),
thx for letting me in!
I will concentrate my efforts most of the time on the _javascript_ side but sometimes it crosses over i guess to the more general side of dltk.
I have currently loads of patches standing out, the things that are purely _javascript_ and easy bug fixes or small improvements i will checkin
the coming days. For others i guess i will first start a discussion if it is meant this way. For example my implementation for Remote Debugging..
(there is some support, some interfaces but not a implementation yet)
JohanOn Tue, Apr 22, 2008 at 4:50 PM, portal on behalf of Andrey Platov <
andrey@xxxxxxxxx> wrote:
technology.dltk Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Johan Compagner. Johan Compagner
is a new full Committer on the technology.dltk project.
Welcome!
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae
