Community
Participate
Working Groups
hi, when in self-hosting mode, it would be really great if stack traces in the dialog opened via the Error Log, could hyperlink to the source code/line in the hosting instance of eclipse. If its not a self-hosting session then it could revert to the current behaviour. thanks, Andrew
tagging bugday
Created attachment 82400 [details] mylyn/context/zip
It makes sense to support this in hosting instance, instead of hosted since with bug 73151 it'll be pretty easy to open hosted Eclipse log.
I guess direct coupling with JDT won't be a good idea, however platfrom hyperlink detectors introduced in Eclipse 3.3 will work out of the box for any SourceViewer widget. So if you convert text area showing stack trace into SourceViewer it would work out of the box, i.e. Mylyn has java stack trace hyperlink detector that works with any text content (perhaps it should be promoted to JDT, so stack trace console could use it too). See /org.eclipse.mylyn.java.ui/src/org/eclipse/mylyn/internal/java/ui/JavaStackTraceHyperlinkDetector.java /org.eclipse.mylyn.java.ui/src/org/eclipse/mylyn/internal/java/ui/JavaStackTraceFileHyperlink.java
(In reply to comment #4) >/org.eclipse.mylyn.java.ui/src/org/eclipse/mylyn/internal/java/ui/JavaStackTraceHyperlinkDetector.java >/org.eclipse.mylyn.java.ui/src/org/eclipse/mylyn/internal/java/ui/JavaStackTraceFileHyperlink.java Thanks Eugene! Since LogView happens to be included in RCP, I guess Chris would be really upset to add any new dependency there. For me it 'd be perfect to have a service (like all good OSGi do), that I could register to and get links from anyone in the air. Thanks for good context to start :)
(In reply to comment #5) > Since LogView happens to be included in RCP, I guess Chris would be really > upset to add any new dependency there. SourceViewer is in o.e.jface.text.source. It isn't acceptable to use that?
I'm not against it, we already have an optional dependency on org.eclipse.ui.ide which includes jface.text If you want to see how we deal with this Jacek, you can check out: org.eclipse.ui.internal.views.log.LogView.createOpenLogAction() It should be possible to do something similar :P
(In reply to comment #7) > I'm not against it, we already have an optional dependency on org.eclipse.ui.ide > which includes jface.text > > If you want to see how we deal with this Jacek, you can check out: > org.eclipse.ui.internal.views.log.LogView.createOpenLogAction() > > It should be possible to do something similar :P yep, I actually have it almost ready. btw. ui.ide seems to not reexport jface.text. What concerns me now is that there are quite heavy dependencies to resolve and open a java type from hyperlink. They are: debug.ui - for some interfaces jdt.debug.ui - for OpenTypeAction - to search workspace for java type jdt.debug.core - as jdt.debug.ui require it's classes workbench.texteditors - for ITextEditor and jumping to certain line ...but I think I'll do the same as in createOpenLogAction() and second, that OpenTypeAction is internal and logview project doesn't allow internal things ...maybe I'll come up with better implementation :P anyway, it's sunday = no programming :)
Jasek, you don't need to put all of those dependencies into the log viewer. As long as you use SourceViewer, platform hyperlink detectors will just work and that is the only change you need there. So hyperlinking will happens automatically once Mylyn is installed. To cover case when there is no Mylyn you could copy stacktrace hyperlink detector from Mylyn into the pde.ui. Ideally that hyperlink detector need to be promoted to JDT.
(In reply to comment #9) > Jasek, you don't need to put all of those dependencies into the log viewer. As > long as you use SourceViewer, platform hyperlink detectors will just work and > that is the only change you need there. > To cover > case when there is no Mylyn you could copy stacktrace hyperlink detector from > Mylyn into the pde.ui. Ideally that hyperlink detector need to be promoted to > JDT. I'm testing without Mylyn. And from what I've found, hyperlink detectors registry is in workbench.texteditors. And to be able to use them, I have to use TextViewerConfiguration (from workbench.texteditors). So I decided to do a minimal implementation on my own (something like Mylyn classes) - this led to all the crazy dependencies. Yes Euguene, moving detectors to pde.ui is very good idea, specially as there are already some hyperlink detectors. btw. I would also make a cosmetic change to Mylyn stackTrace regexp: \\S*.{1}java:\\d*\\){1} to \\S*\\.java:\\d*\\) as it covers things as: org.a.b.C.do(C-java:123), but should only: org.a.b.C.do(C.java:123) and {1} at the end is imo unnecessary. does that change anything? thanks for your help.
Created attachment 88718 [details] didn't I tell that? ;))))
(In reply to comment #10) > btw. I would also make a cosmetic change to Mylyn stackTrace regexp: > \\S*.{1}java:\\d*\\){1} > to > \\S*\\.java:\\d*\\) > > as it covers things as: > org.a.b.C.do(C-java:123), but should only: > org.a.b.C.do(C.java:123) > > and {1} at the end is imo unnecessary. > does that change anything? Can you please fill a bug report on Mylyn about this
(In reply to comment #10) > I'm testing without Mylyn. And from what I've found, hyperlink detectors > registry is in workbench.texteditors. And to be able to use them, I have to use > TextViewerConfiguration (from workbench.texteditors). So I decided to do a > minimal implementation on my own (something like Mylyn classes) - this led to > all the crazy dependencies. I've been using TextSourceViewerConfiguration from org.eclipse.ui.editors plugin. Perhaps also not an option for the log viewer. On the other hand, if you can use that as an optional dependency and use TextSourceViewerConfiguration when available, it would allow to use platform hyperlink detectors, i.e. from mylyn or pde.ui.
Created attachment 88730 [details] patch Following patch contains: 1. org.eclipse.pde.ui: - hyperlinkDetectors extension for LogView - JavaStackTraceHyperlinkDetector - detects hyperlinks in text. It's written the same way as Mylyn's JavaStackTraceHyperlinkDetector.java but has a bit modified regexp and supports closing logview event details window on hyperlink click - JavaStackTraceHyperlink - finds linked type, opens it's editor and jumps to appropriate line. It's based on org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink with very slight changes to support closing event details window As agreed earlier, PDE.UI is best place to put hyperlink detectors, because it has all necessary dependencies. However I'm not sure which package is the best, as there are no logview specific packages in PDE.UI 2. org.eclipse.ui.views.log - new optional dependency on org.eclipse.jface.text There's org.eclipse.ui.ide which depends on jface.text, but it's also optional. - new optional dependency on org.eclipse.ui.editors to have HyperlinkDetectorsRegistry - extension hyperlinkDetectorTargets defining "org.eclipse.ui.views.log" target - HyperlinkStackTraceViewer class which encapsulates anything that's optional. - Event details dialog uses either new HyperlinkStackTraceViewer, or plain old SWT Text widget. I've tested with different setups of optional dependencies. I haven't tested with Mylyn detectors. They might not be that good, because they'll not close event details window after hyperlink jump.
(In reply to comment #12) > Can you please fill a bug report on Mylyn about this I've created bug 217630 (In reply to comment #13) > I've been using TextSourceViewerConfiguration from org.eclipse.ui.editors > plugin. Perhaps also not an option for the log viewer. On the other hand, if > you can use that as an optional dependency and use > TextSourceViewerConfiguration when available, it would allow to use platform > hyperlink detectors, i.e. from mylyn or pde.ui. 100% agree. Earlier I used workbench.texteditors instead of org.eclipse.ui.editors by mistake.
(In reply to comment #14) > - Event details dialog uses either new HyperlinkStackTraceViewer, or plain old > SWT Text widget. Out of curiosity, why did you need custom viewer? > I've tested with different setups of optional dependencies. > I haven't tested with Mylyn detectors. They might not be that good, because > they'll not close event details window after hyperlink jump. I've been wondering why "Log View" uses dialog instead of the editor? I.e. compare its interaction with the History view, which does use editors...
(In reply to comment #16) > Out of curiosity, why did you need custom viewer? That's good question. Actually it's not a custom viewer, but just contains SourceViewer. I wanted to keep jface.text dependency optional so if I'd put SourceViewer directly into our dialog, user trying to open dialog without it would get ClassNotFoundException. Another way would be to extend our dialog: class EventDetailsDialog extends TrayDialog; class OptionalEventDetailsDialog extends EventDetailsDialog; and then use one or other as dependencies allow. I didn't think about that earlier, but now as functionality works, EventDetailsDialog could be refactored to support that. JFace.text could be left as mandatory dependency, but given it's not in RCP feature, I doubt we really need it. My rationale here is that there's been discussion some time ago to get LogView out of PDE, because lots of people want to use it in their RCPs. So we actually have two audiences: developers (who don't mind any new dependencies) and rcp integrators (who do mind). And rcp integrators don't need hyperlinks at all. > I've been wondering why "Log View" uses dialog instead of the editor? I.e. > compare its interaction with the History view, which does use editors... sounds nice :) I've created bug 217644 for it.
As posted in bug 217644, why not just have jdt.debug.ui contribute an action to open an error log entry in the stack trace console? Also, I'd like to learn more about how the error log view will show logs from different targets. If this is the case, the log view should somehow show in its title where the log view is coming from (based on launch config name, or something like that).
> Also, I'd like to learn more about how the error log view will show logs from > different targets. If this is the case, the log view should somehow show in its > title where the log view is coming from (based on launch config name, or > something like that). This just went a few builds ago, it will show you the location of your log if it's based on a launch config versus say the workspace.
(In reply to comment #19) > This just went a few builds ago, it will show you the location of your log if > it's based on a launch config versus say the workspace. Glag I'm on top of things :-) Is this the "import log" feature?
yap!
(In reply to comment #18) > As posted in bug 217644, why not just have jdt.debug.ui contribute an action to > open an error log entry in the stack trace console? Darin, would it be possible for jdt.debug.ui to contribute stack trace hyperlink detector too?
(In reply to comment #22) > Darin, would it be possible for jdt.debug.ui to contribute stack trace > hyperlink detector too? Open a bug against jdt.debug. It's unfortunate that console and jface have different definitions of IHyperlink - I see then both went into 3.1.
see https://bugs.eclipse.org/bugs/show_bug.cgi?id=217644#c12 >- Hyperlinking from the current event dialog require custom hyperlink detector >and can't use platform hyperlinking support, i.e. because of the optional >dependencies and special need to close dialog when clicking on hyperlink)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
