|
|
|
Re: Debugging DSL code [message #1780392 is a reply to message #1780384] |
Mon, 22 January 2018 07:09 |
Steve Hostettler Messages: 81 Registered: June 2016 |
Member |
|
|
Hello Cristian,
thanks for answering. So yes the _trace files are in the jar with .class files that are created using maven (or using eclipse compilation to enable hot deploy). The sources are not in the jars, usually we have separate source jars. Yes the breakpoints are set in the DSL file. I debugged the breakpoint creation and it seems ok. I do not know where to start to debug the actual debugging itself.
Would it help to create a file with the java and dsl sources together? Usually when the sources are not present eclipse presents a dialog to add them.
I should also mentionned that i created a (java application) debug configuration that has the dsl project as source lookup.
[Updated on: Mon, 22 January 2018 07:16] Report message to a moderator
|
|
|
|
|
Re: Debugging DSL code [message #1780401 is a reply to message #1780394] |
Mon, 22 January 2018 08:30 |
Steve Hostettler Messages: 81 Registered: June 2016 |
Member |
|
|
If my understand is correct, the StratumBreakpointAdapterFactory describes whether or not the breakpoint is valid (and this is correctly set as I see the breakpoints enabled in the UI). I do not really see how the breakpoint is treated during runtime in there. Furthermore, most of the time I rely on eclipse compilation rather maven compilation. Therefore, I do not really see why extending the maven plugin is mandatory in a first step.
I though creating a breakpoint in the dsl would have created the corresponding breakpoint in java but this is apparently not the way it works.
Let me also add that the tutorial works perfectly. So it is not my platform but rather something missing in my project(s)
[Updated on: Mon, 22 January 2018 08:48] Report message to a moderator
|
|
|
|
|
Re: Debugging DSL code [message #1780408 is a reply to message #1780407] |
Mon, 22 January 2018 08:54 |
|
i dont understand. is this about setting breakpoints? this is what the class does that i told you.
DebugSourceInstallingCompilationParticipant does the install in eclipse
SourceLookupJob does the source lookup when loading
you can have a look at
JavaBreakPointProvider as well
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
Re: Debugging DSL code [message #1780426 is a reply to message #1780408] |
Mon, 22 January 2018 10:52 |
Steve Hostettler Messages: 81 Registered: June 2016 |
Member |
|
|
So I compared the behavior of the tutorial that works and the behavior within my project and here is what I can report in terms of similarities/differences
1) I can set the breakpoints, in the sense that they appear in the UI and that there is not exception reported.
2) Enable a breakpoint calls the JavaBreakPointProvider.getBreakpointWithJavaLocation and as far as I can tell the IJavaLineBreakpoint instance is correct.
2) On clean project the DebugSourceInstallingCompilationParticipant is invoked and in the method buildFinished generatedJavaFile, traceToSource, rootTraceRegion, dslSourceFile, element are correct. There is one difference with the tutorial in the sense that at line 149 byteCode is null in my case and not in the tutorial.
3) SourceLookup is never invoked but that seems more a consequence than a cause.
At this point the best lead is that installer.installTrace(ByteStreams.toByteArray(contents)); returns null
Investigating there bring me to the TraceAsSmapInstaller class and within the installTrace method
@Override
public byte[] installTrace(byte[] javaClassBytecode) throws IOException {
if (smap == null)
return null;
byte[] updatedByteCode = new SDEInstaller(javaClassBytecode, smap.getBytes()).getUpdatedByteCode();
return updatedByteCode;
}
there the problem is that smap is null and this is coming from the fact that the method createSmapInfo return an empty set.
In my traces there is something strange in the sense they are all marked as targetRegion.isUseForDebugging() = false
Now trying to understand why targetRegion.isUseForDebugging() is false. In other terms why the root TraceNode is marked as useForDebugging=false
[Updated on: Mon, 22 January 2018 11:01] Report message to a moderator
|
|
|
|
|
Re: Debugging DSL code [message #1780439 is a reply to message #1780435] |
Mon, 22 January 2018 13:14 |
Steve Hostettler Messages: 81 Registered: June 2016 |
Member |
|
|
I added the @Traced(useForDebugging=true) on the relevant statements and now the installer.installTrace(ByteStreams.toByteArray(contents)) does not return null anymore.
The debugger still does not suspend the execution when I put a breakpoint in the dsl code but when put a breakpoint in the generated java code, the execution suspends and display the dsl code on the correct line and the step by step execution happens in the dsl code with proper variable display.
Almost there ... but not quite
Any idea?
[Updated on: Mon, 22 January 2018 13:38] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Debugging DSL code [message #1780605 is a reply to message #1780512] |
Wed, 24 January 2018 14:27 |
Steve Hostettler Messages: 81 Registered: June 2016 |
Member |
|
|
After a deep (very deep) debug session, I figured it out and it was .... very very stupid.
@Override
protected String getClassNamePattern(XtextResource state) {
String name = "*SampleActivity*";
return name;
}
does not work but
@Override
protected String getClassNamePattern(XtextResource state) {
String name = "com.wkfsfrc.generated.sample_1_0_0.SampleActivity*";
return name;
}
does. It appears the pattern only accepts * as postfix. Did not investigate much more as I can always generate the prefix correctly. To my defense, what is an appropriate pattern was not clearly specified. :)
Good thing is that I had the opportunity to learn about the JDT
[Updated on: Wed, 24 January 2018 14:44] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.03647 seconds