I doubt that this is the source.
This is the Document Validation code for the local part:
As you see:
WIP this does not do anything yet
It is just a boilerplate introduced some while ago.
What may work from the local LSP part (not tested though) is item completion while typing (only with http connections).
Those should then get suggested in the code editor.
*** EDITED ***
Hmm. It now happened to me at least twice that at times VSC was not showing any errors then when opening the same fileset again later it was suddenly full of (correct) warnings on my code.
I believe it has simply stopped working in the first place.
One thing to irritate was VSC kept complaining about deprecated parameters. There weren’t any in settings.json but turned out there’s also C:\Users<MyWinUser>.vscode\extensions\openhab.openhab-1.0.0-ci-5aaea7a\package.json` and it still had those old parameters. When I deleted them there the warning disappeared.
VSC was also spitting errors on the host it couldn’t connect to.
That package.json file also contained an old (now wrong) hostname parameter for the host to connect to and after replacing that the warning disappeared.
So thing is package.json seems to have precedence over settings.json ??
I also got the output below:
Any hint how to proceed from here to debug what’s going on ?
openHAB vscode extension has been activated
[Error - 19:20:11] Request textDocument/definition failed.
Message: Internal error.
Code: -32603
java.util.concurrent.CompletionException: java.lang.ClassCastException: class org.eclipse.xtext.common.types.access.TypeResource cannot be cast to class org.eclipse.xtext.resource.XtextResource (org.eclipse.xtext.common.types.access.TypeResource is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @d67b05; org.eclipse.xtext.resource.XtextResource is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @2d855)
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:704)
at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at org.eclipse.xtext.ide.server.concurrent.AbstractRequest.logAndCompleteExceptionally(AbstractRequest.java:73)
at org.eclipse.xtext.ide.server.concurrent.ReadRequest.lambda$doRun$0(ReadRequest.java:69)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassCastException: class org.eclipse.xtext.common.types.access.TypeResource cannot be cast to class org.eclipse.xtext.resource.XtextResource (org.eclipse.xtext.common.types.access.TypeResource is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @d67b05; org.eclipse.xtext.resource.XtextResource is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @2d855)
at org.eclipse.xtext.ide.server.WorkspaceManager.doRead(WorkspaceManager.java:436)
at org.eclipse.xtext.ide.server.findReferences.WorkspaceResourceAccess.readOnly(WorkspaceResourceAccess.java:36)
at org.eclipse.xtext.ide.server.symbol.DocumentSymbolService.doRead(DocumentSymbolService.java:332)
at org.eclipse.xtext.ide.server.symbol.DocumentSymbolService.getDefinitions(DocumentSymbolService.java:112)
at org.eclipse.xtext.ide.server.symbol.DocumentSymbolService.getDefinitions(DocumentSymbolService.java:99)
at org.eclipse.xtext.ide.server.LanguageServerImpl.lambda$definition$24(LanguageServerImpl.java:603)
at org.eclipse.xtext.ide.server.WorkspaceManager.doRead(WorkspaceManager.java:438)
at org.eclipse.xtext.ide.server.LanguageServerImpl.definition(LanguageServerImpl.java:602)
at org.eclipse.xtext.ide.server.LanguageServerImpl.definition(LanguageServerImpl.java:590)
at org.eclipse.xtext.ide.server.LanguageServerImpl.lambda$definition$23(LanguageServerImpl.java:581)
at org.eclipse.xtext.ide.server.concurrent.ReadRequest.lambda$doRun$0(ReadRequest.java:66)
... 5 more
EDIT on VSC start I get this on the OH server, reproduceably so. Running 1.0beta about 3 days old
2021-04-04 19:19:53.837 [INFO ] [ext.common.types.util.TypeReferences] - Couldn't find JvmType for name 'org.openhab.core.model.script.actions.Semantics' in context org.eclipse.xtext.xbase.resource.BatchLinkableResource@d073ff uri='file:///etc/openhab/rules/Energiemanagement.rules'
java.lang.IllegalStateException: Resource has not been loaded
at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeProvider.findTypeByClass(ReflectionTypeProvider.java:200) ~[bundleFile:?]
at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeProvider.findTypeByClass(ReflectionTypeProvider.java:151) ~[bundleFile:?]
at org.eclipse.xtext.common.types.access.reflect.ReflectionTypeProvider.findTypeByName(ReflectionTypeProvider.java:88) ~[bundleFile:?]
at org.eclipse.xtext.common.types.util.TypeReferences.findDeclaredType(TypeReferences.java:256) [bundleFile:?]
at org.eclipse.xtext.common.types.util.TypeReferences.findDeclaredType(TypeReferences.java:233) [bundleFile:?]
at org.eclipse.xtext.xbase.scoping.batch.ImplicitlyImportedFeatures.getTypes(ImplicitlyImportedFeatures.java:82) [bundleFile:?]
at org.eclipse.xtext.xbase.scoping.batch.ImplicitlyImportedFeatures.getExtensionClasses(ImplicitlyImportedFeatures.java:76) [bundleFile:?]
at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.newSession(XbaseBatchScopeProvider.java:121) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:164) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:140) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.resolveTypes(CachingBatchTypeResolver.java:81) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:58) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:54) [bundleFile:?]
at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:38) [bundleFile:?]
at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:135) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver.doResolveTypes(CachingBatchTypeResolver.java:54) [bundleFile:?]
at org.eclipse.xtext.xbase.typesystem.internal.AbstractBatchTypeResolver.resolveTypes(AbstractBatchTypeResolver.java:70) [bundleFile:?]
at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:72) [bundleFile:?]
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:166) [bundleFile:?]
at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:505) [bundleFile:?]
at org.eclipse.xtext.build.IncrementalBuilder$InternalStatefulIncrementalBuilder.lambda$launch$2(IncrementalBuilder.java:266) [bundleFile:?]
at com.google.common.collect.Iterators$6.transform(Iterators.java:783) [bundleFile:?]
at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47) [bundleFile:?]
at com.google.common.collect.FluentIterable.copyInto(FluentIterable.java:791) [bundleFile:?]
at org.eclipse.xtext.build.ClusteringStorageAwareResourceLoader.executeClustered(ClusteringStorageAwareResourceLoader.java:69) [bundleFile:?]
at org.eclipse.xtext.build.BuildContext.executeClustered(BuildContext.java:55) [bundleFile:?]
at org.eclipse.xtext.build.IncrementalBuilder$InternalStatefulIncrementalBuilder.launch(IncrementalBuilder.java:259) [bundleFile:?]
at org.eclipse.xtext.build.IncrementalBuilder.build(IncrementalBuilder.java:404) [bundleFile:?]
at org.eclipse.xtext.build.IncrementalBuilder.build(IncrementalBuilder.java:386) [bundleFile:?]
at org.eclipse.xtext.ide.server.ProjectManager.doBuild(ProjectManager.java:106) [bundleFile:?]
at org.eclipse.xtext.ide.server.BuildManager.internalBuild(BuildManager.java:190) [bundleFile:?]
at org.eclipse.xtext.ide.server.WorkspaceManager.lambda$didChangeFiles$4(WorkspaceManager.java:279) [bundleFile:?]
at org.eclipse.xtext.ide.server.LanguageServerImpl.lambda$runBuildable$15(LanguageServerImpl.java:453) [bundleFile:?]
at org.eclipse.xtext.ide.server.concurrent.WriteRequest.run(WriteRequest.java:52) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
The documented hierarchy is pretty clear for settings.
It will choose form the following sources in the presented order:
settings.json in your .vscode folder)So what may happened is that vscode does not clean out those folders very well during an update and knows some default value somewhere, where it should not be.
I tried to suppress deprecated parameter warnings, when there was just a default value in place.
Maybe we should point to the stackoverflow article for completely uninstalling a extension befor an update.
Those errors are send from the remote Language server of your openHAB instance.
Maybe @wborn can give some information. He fixed the last problems on LSP side.
I am not able to do anything over there.
The Language Server is implemented as a bundle in Java in openHAB core.
Possible, when the connection is erroring.
It will not try to reopen after some tries until you restart the extension, from what i know.
I’m still getting ‘deprecated’ warnings on every start.
I’ve browsed settings.json and package.json but I’m still getting this warning.
Global settings go to settings.json don’t they? So that should cover your possibilities.
Could you please at least add an output which parameter this refers to ? I likely have one that I thought is current but the extension considers it to not be - just that I do notknow which one that is.
Gnah.
I had something like this built in already, but it just produces an output when a deprecated setting “is used by an extension part” but not when it is set at all.
That’s not how it was supposed to be, but it seems that it has anded up the wrong way in a refactoring.
I will put out a list of deprecated parameters in the openHAB extension Output.
Should we add a Button to the warning to open the output directly?
Edit:
Showcase
I will link the beta version when it is available.
Thanks. Hmm, it says
Usage of deprecated config => openhab.consoleCommand <= detected
But isn’t that the correct, new name ? At least the settings page says so.
Do you have configured the consoleCommand on purpose?
How did you configure it, if the answer is yes? (User or workspace setting?)
Can you also check if you still have openhab.karafCommand configured somewhere maybe?
I will try to reproduce the behavior based on your config situation in my debugging environment then.
yes, user settings
It was indeed a small bug in the karaf parameter check.
Continuing here, since the anonuncement is closed and the issue is discussed here with its history:
Did you check you configuration in all possible places?!
User settings
Workspace settings?
Here is a gif of how i would search for the specific setting in the different scopes and reset it to default:
Since there are many ways to configure the extension, i can only point to the settings doc article for further investigation.
https://code.visualstudio.com/docs/getstarted/settings
It show possible paths where settings might be stored and hot to fully rest user settings.
Anyway i think it would be good to give an indicator on which scope(s) a deprecated setting is modified in one of the next extension versions.
I will prepare and contribute this extended logging.
I only have user settings and it’s right there. No .vscode directories, I checked.
And did you try to reset the karaf setting too like shown in the gif?
Yes. I’ve now reset the new setting, that now seems to have done the trick !?
Probably some cached data from one of the beta versions.
Config handling in code is pretty confusing sometimes and has caused several problems over the time…
Info only: I meant to try out new extension on OH2-Windows-localhost combination, but never found the needed round-to-it.
Unexpectedly for me, it force-fed me 1.0 anyway, auto updated.
Some whinges about config json as expected, easily corrected as it suggested. I was prepared for that, but it may come as surprise to some users.
No Auth stuff used in OH2 setting.
All working well - thankyou!
Observation - the extension readme displayed in VSC still talks OH 2.x, omits OH3
I had the issue with the extension showing me an error about depreciated configuration too:
However this is not configured anywhere:
I also searched in the settings.json and could not find the setting.
Reloading the window (as shown in the GIF) didn’t help either.
Strangely enough I was able to fix it by just adding the new property to the settings.json:
"openhab.connection.basicAuth.username": "" and the extension did not complain anymore
Same what happened to me. @Confectrician I think that’s still a bug (and unrelated to caching as I had this issue across many restarts)
Maybe you have some settings in:
\openHAB-conf\.vscode\settings.json
on openHab server and not in VSCode itself.