Community
Participate
Working Groups
RC1 * start a new empty workspace * select "Debug As > Runtime Workbench" * a target workbench starts in debug mode * suspend the main thread -> no source will be found (if in SDK code) The only thing on the source lookup path in this case is src.zip from the JRE. Not critical, but makes a nice demo (when it works :-)
This would have all been possible if you went to the Plugins view, selected all the plugins, and from the context menu you selected Add to Java Search. This would create the fake Java project with three tiny files. This project is added to the source debug lookup path so you won't be prompted for source. You would also be able to create type hierarchies and all other fun activities without you having imported a single class into your workspace. Are you suggesting that this is still too much?
Nothing like help "on demand" :-) I'm not going to push on this one, the only reason I filed the bug was because debug had a bug file against us to allow the runtime workbench launch shortcut to be enabled with no selection. Thus you could start a workbench and run/debug a workbench without doing anything. It would be a better demo it you could also see source, but (like I say) it's not critical. Feel free to close this one.
A functionality like this one would definitely demo well and be useful, especially since PDE clients are getting spoiled and are expecting more and more magic :-) However, I don't know if you remember (probably not :-), you and I had this conversation before. The only way this could happen is if Debug had some kind of source lookup participant extension point, which PDE can plug into. When Debug can't find source, it would ask PDE on demand. I believe you said that such an extension point exists in the new source lookup. The other issue was the fact that Debug is plug-in agnostic, as it should be. So when looking for source, it could only give PDE a class in the stack frame, and PDE would have to reverse-engineer the process to figure out what plug-in this class is coming from to find the attached source which would be in an equal but separate plug-in. This is where we left it. You never commented on whether the latter issue can be resolved. So if all the pieces are in place in Debug, PDE could certainly address it post-3.0.
The extension point exists - a source path computer. The source path computer is associated with a launch configuration type, via the "sourcePathComputerId" attribute on the launchConfigurationType extension. Currently, PDE uses the standard "java source path computer" which consults the "old" "source path provider" mechanism to compute the source lookup path. PDE provides the "WorkbenchSourcePathProvider". One approach would be to modify it to provide a different source path when there are no plug-ins in the workspace.
cc Jeff as this issue comes down to exactly what we discussed with Darin a few weeks ago, where PDE would have to supply source lookup on demand when debugging a runtime Eclipse app. Step 1 would be for the debugger to give us the classloader. I believe Darin already did that portion. Next step would be for the runtime to add a method on the classloader that will return the id of its plugin upon reflection.
Right, easy enough but two questions - Can the method be private? We are presumably calling it over the wire by some sort of reflection anyway. Making it private is just an added safety thing. - Do we want the bundle symbolic name (i.e., the string id of the bundle) back? This is likely ok for now but in the general case there may well be two bundles with the same name... By CC to Tom, we are talking about adding a method like private String getBundleSymbolicName() { return hostdata.getBundle().getSymbolicName(); } to DefaultClassLoader. I was looking for a way to use PackageAdmin.getBundle (Class) but the problem is getting the service instance. We are in the debugger talking over the wire so the fewer message sends the better. We have the classloader so the above method should do it. Thoughts?
when we launch a runtime app, we (PDE) always pass you a list of bundles with unique ids. The list would never include conflicting ids.
id meaning symbolic name, of course.
If you are using reflection why do you need a new method? Can't you just access the hostdata slot with reflection and call the necessary methods on it? This might prove to be too painful, but I know it is possible. I don't really have an issue with adding the methods to the classloader. We could add two methods, one to get the symbolic name and one to get the version (just incase we do have multiple versions). Note that you should get the information from the hostdata, not the bundle object referenced by the hostdata. So the methods would look like this: protected String getBundleSymbolicName() { return hostdata.getSymbolicName(); } protected Version getVersion() { return hostdata.getVersion(); } I would make the methods protected to allow extending classes access. They already have access to hostdata so these would really just be convenience methods. Note that Class.getMethod(s) does not return non-public methods so you will have to use Class.getDeclaredMethod. The disadvantage of this method is that it only gives you methods defined by the class itself, not any methods inherited from its superclass. So you will have to walk up the class hierarchy to find the method since EclipseClassLoader extends DefaultClassLoader.
Darin will have to weigh in on what is the best/most efficient thing to do. My impressoin is that we have a classloader proxy and ideally want to send it one message and get back the id we need. Perhaps this should be the id_version for future proofing... PDE can strip off the version. Wassim, in the general case you can't give unique ids and yet still allow multiple versions of the same plugin. This all works today because most plugins are marked as singletons. This is not true in general or OSGi. We don't need to fix it now but should avoid building on that assumption if we can.
what happens if we are loading a class that physically resides in a fragment JAR? Fragments don't have their own classloaders.
is it possible for the plugin classloader's getBundleSymbolicName() method to return the symbolic name of the fragment in that case?
The classloader of the host is always used to load classes from a fragment. Not sure how we would return the symbolic name of a fragment from the getBundleSymbolicName on the classloader. We would have no context because this method is on the classloader not the class. In PDE, don't you know what fragments are attached to a host?
ok, PDE will look in fragments (if any) if we don't find the class in the plug- in. I do and do and do for you :-)
*** Bug 43342 has been marked as a duplicate of this bug. ***
marking as fixed. You can now debug an Eclipse application and even stop in Main without having a single class in your host workbench. Thanks to Darin for a nice Debug framework to extend and to Dani for fixing bug 54900.
