Closed goevexx closed 4 years ago
Hi @goevexx , first idea looking at the error Unable to publish (Full) to the server: Extension backend error - failed to publish in time Source: Remote Server protocol UI (Extension)
is that it takes too much time to publish so maybe you could use the async method.
To enable this, go to the settings (Command Palette (Ctrl+Shift+P) -> search for Preferences: Open Settings (JSON)
) and add "rsp-ui.enableAsyncPublish": true
to the json file and save.
Do you still have the error?
Thanks for the quick response. This solved the error!
But it still deploys to C:\Users\nmo\.rsp\redhat-server-connector\runtimes\installations\wildfly-1800finalruntime\wildfly-18.0.0.Final\standalone\deployments
instead of C:\Users\nmo\.rsp\redhat-server-connector\runtimes\installations\wildfly-1800finalruntime\wildfly-18.0.0.Final\test_project\deployments
.
So I've added the following configuration to the server, just to make sure that these are set correctly (it should even work without these properties set).
Djboss.server.config.dir=C:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\test_project\\configuration
Djboss.server.deploy.dir=C:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\test_project\\deployments
Unfortuantely, the configuration doesn't affect it. Fortunately, Red Hat Server Connector's stdout has an error I've not recognized yet.
08:34:12.044 [pool-1-thread-1] ERROR o.j.t.r.s.s.p.AbstractFilesystemPublishController:269 - Error publishing module {0} to server {1}
java.nio.file.FileAlreadyExistsException: C:\Users\nmo\.rsp\redhat-server-connector\runtimes\installations\wildfly-1800finalruntime\wildfly-18.0.0.Final\standalone\deployments\WafePortal.war\.svn\pristine\21\211530012463eaa835a0a48cb245fb041c103a2c.svn-base
at java.base/sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:123)
at java.base/sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:279)
at java.base/java.nio.file.Files.copy(Files.java:1294)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController$CopyFileVisitor.visitFile(AbstractFilesystemPublishController.java:436)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController$CopyFileVisitor.visitFile(AbstractFilesystemPublishController.java:1)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2724)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2796)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController.fullPublishCopyExplodedModule(AbstractFilesystemPublishController.java:266)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController.fullPublishCopyModule(AbstractFilesystemPublishController.java:240)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController.copyModule(AbstractFilesystemPublishController.java:187)
at org.jboss.tools.rsp.server.spi.publishing.AbstractFilesystemPublishController.publishModule(AbstractFilesystemPublishController.java:162)
at org.jboss.tools.rsp.server.wildfly.servertype.publishing.WildFlyPublishController.publishModule(WildFlyPublishController.java:63)
at org.jboss.tools.rsp.server.wildfly.servertype.AbstractJBossServerDelegate.publishDeployable(AbstractJBossServerDelegate.java:346)
at org.jboss.tools.rsp.server.model.AbstractServerDelegate.publish(AbstractServerDelegate.java:486)
at org.jboss.tools.rsp.server.model.AbstractServerDelegate.publish(AbstractServerDelegate.java:457)
at org.jboss.tools.rsp.server.model.ServerModel$1.run(ServerModel.java:673)
at org.jboss.tools.rsp.server.spi.jobs.SimpleJob.run(SimpleJob.java:96)
at org.jboss.tools.rsp.server.jobs.JobManager.lambda$0(JobManager.java:86)
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)
Can you do anything with it?
I'll look into this.
We've always had a tough time deciding how exactly to manage three competing interests. 1) Most configuration should be done via the standalone.xml, and tools should just discover it 2) Users won't always want to modify standalone.xml and may instead prefer to change command line args 3) Users may sometimes do really weird things like set up multiple functional deploy directories, making it impossible for tools to know which one to copy to, and so users should have the right to override the behavior of the tools via settings.
The obvious problem here is, it gets kinda circular. If the users edit the standalone.xml (or other config file), but then ALSO edit the command line arguments, which should we trust? If the user edits a server setting, we SHOULD update the command line args for them to make sure the server is launched with the arguments that match that, but, if the user has already customized the cmdline args, we'd be interfering with their choices. And then we wouldn't know which location to trust.
I'll be trying to find a more coherent workflow here and see what I can do. For now, I'm adding a setting for the tools / rsp only (ie not for the app server) as to where the tools will copy files when publishing / deploying. At the very least, this should solve your usecase, if not my broader issue.
See for example https://github.com/redhat-developer/vscode-rsp-ui/issues/103
So... this issue is kinda fixed. To start, the following commit gives users the right to override the directory that the rsp will copy deployments into.
The way to use this is to set as a property in your server's json file where key = wildfly.server.deploy.directory and use either an absolute filesystem path or a path relative to your server home directory as the value.
Obviously it'd be nicer to parse your command line, read the various flags, then read the various underlying xml files, to properly determine exactly what you want done. But this becomes circular, so for now, this is the best we can do.
Hope this helps. Let me know if it works for you.
Hey guys, I hope you can help me. We are looking for a way to work with vscode in our company in means of using wildfly within vscode. So this plugin seems to be useful. There are already deployments from eclipse, which shall also run in vscode. Trying to run a deployment on a WildFly18 server it fails as early as the server is published. The notification says: "Unable to publish (Full) to the server: Extension backend error - failed to publish in time Source: Remote Server protocol UI (Extension)" Red Hat RSP Server (stderr) says :
But thats similar to usage in eclipse. It doesn't influence the process.
The .wars are deployed in
standalone/deployments
directory, though it is configured to usetest_project
as base directory.The server configuration looks like this:
Java Version:
Any suggestions?