SlickEdit Product Discussion > SlickEdit®
Java Live Errors refuses to recognize some classes
patrick:
Ok, so I fixed the path problem I noticed with logging last night. I suspect it's not the cause of your problem, so I've also attached an updated RTECompiler.class to do extra logging for _all_ of the flags we pass to the compiler, right before Live Errors performs the compile. So that should capture any problems with the classpath that might have been introduced on the Live Errors code path.
For the vsRTE.dll:
1) Exit SlickEdit if it is running.
2) Go to your SlickEdit install directory, go to the win directory, and rename/backup the existing vsRTE.dll
3) Copy in the vsRTE.dll that's attached to this post.
4) Restart. See if Live Errors still complains about your Log4j2 classes.
If it does still have problems:
1) Exit SlickEdit.
2) Go to the SlickEdit install directory, and from there go to the toolconfig\rte directory. Rename/backup the existing RTECompiler.class, and then copy in the RTECompiler.class that's attached to this post.
3) Restart SlickEdit.
Now, whenever Live Errors is triggered by an edit, the full set of compiler flags will be appended to %TEMP%\CompilerFlags.txt. There will be one argument per line.
I'd look at that first and check to see if the log4j2 entries are correct, and there aren't any mangled paths or odd looking compiler flags being sent. (note: the options in the file will not include the path to the source file of the buffer it's doing a check on, like you would do running a "javac" from the command line. We pass the buffer contents directly into the compiler API, so it doesn't appear with the other options).
Hopefully, that shows something wrong, because the alternatives are probably going to be harder to track down. Let me know what you see, and we'll go from there.
rygaard:
Patrick,
I tried the new vsRTE.dll, and it did not resolve the issue (as you suspected).
I loaded the new RTECompiler.class and reviewed the options passed to Live Errors. I can't find anything wrong there.
My gut feeling is this is not a SlickEdit problem. I suspect I am doing something odd without knowing it. I'm not certain of this hypothesis because it does not explain the differences between project-compile and Live Errors.
I need to pursue this because logging calls are sprinkled through almost all of my classes, and this is negating all advantages of Live Errors.
For now, the ball is in my court. I'll try to reproduce this in a simple project, and I'll let you know what I learn from that.
rygaard:
A colleague seems to have resolved the problem. The fix was:
* Select the Options->Languages->Application Languages->Java->Live Error Profiles->Enable (override java compiler integration) check box,
* Click "Apply" and "OK" to close the Options dialog box,
* Deselect the Options->Languages->Application Languages->Java->Live Error Profiles->Enable (override java compiler integration) check box, then
* Click "Apply" and "OK" to close the Options dialog box.
???
When I built a simple project with just one Java source file, the problem did not occur. I built this simple project from scratch.
My gut tells me that some configuration (I have no idea what) was fouled in SlickEdit, and toggling the flag described above caused SlickEdit to re-read its configuration, thereby resolving the problem. The fact that the problem did not recur when I built a project from scratch supports this hypothesis.
patrick:
Hmm, I'm not sure. Toggling that would make it re-read some of the configuration as the Java Live Error thread is stopped and started, but that would also happen on when exiting and restarting the editor. I didn't think it worked for you after the editor was restarted.
I'll double check what the code does with that switch though, maybe there's some initialization detail I'm forgetting.
rygaard:
For some reason, this problem returned. This time, I can't get it repaired.
Any suggestions would be most appreciated.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version