[jdt-debug-dev] Re: [platform-debug-dev] Which came first: the launch, t

[Darin_Wright@xxxxxxx]

A change notification is fired for a launch when a debug target or process is added to a launch.

Darin

Matt_Lavin@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 03/27/2002 11:23 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:        jdt-debug-dev@xxxxxxxxxxx         Subject:        Re: [platform-debug-dev] Which came first: the launch, the debug target, or the process?

I agree that it would be nice to have a strict lifecycle for launch objects, but I have a concern about the proposed cycle.  In step 3, the launch is registered and listeners will hear the launch, but the process will not be started yet.  In the current design, the launch is registered after the launch, and ( I think ) you can assume that the program has actually been started succesfully.  In the CDS launcher, and I would guess the JUnit launcher, the launch listener tries to connect to the newly launched program.  How would launchers know when, or if, the launch actually started a process?   

I don't really understand what the launchChanged method is for, but perhaps an event could be thrown when the launch has really started, ie. after step 5.

Darin_Wright@xxxxxxx Sent by: platform-debug-dev-admin@xxxxxxxxxxx 03/27/2002 11:55 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx        cc:        jdt-debug-dev@xxxxxxxxxxx        Subject:        [platform-debug-dev] Which came first: the launch, the debug target, or the process?

Currently, the debug launch story does not specify a strict lifecycle of launch objects. That is, there is no specification of when a launch object is created, and when a debug target is added to that launch, or if a debug target can exist before its corresponding launch, etc. This can be problematic, as debug event listeners may receive event notification for a target or process that is not registered with a launch object yet (making it hard for clients to identify debug targets). 

To make the launch process better specified (and more predictable), the debug team proposes the following: 
(1) An empty launch object will be created by a launch configuration when its launch method is called (since there is only one shared implementation of ILaunchConfiguration, all clients inherit this behavoir for free). The launch is empty in the sense that it does not contain any debug targets or system processes at this point. 
(2) The launch object will be seeded to point to the associated launch configuration being launched 
(3) The launch object will be registered with the debug plug-in 
(4) The launch object will be passed to the configuration's associated delegate to perform the actual launch. 
(5) The delegate will launch/create processes and debug targets and ADD them to the provided (already existing) launch object 

To make java launching more predictable, the debug team proposes the following 
(1) A java debug target constructor/factory method should provide the launch object with which to associate the target - this way a debug target will always be contained in a launch, and will be identifiable via its launch object or lanuch configuration. 

This change will require a breaking API change - launch config delegates will need to accept a launch object as an argument, rather than returning a launch object. As well, the creation of java debug targets will require a launch object. 

Please comment ASAP if you have concerns, as we want to get this change into the Milestone 5 release. 

Thanks, 

Darin