search

redhat-developer / vscode-server-connector

📦 Connects Visual Studio Code to your server adapters and run, deploy apps !!
Eclipse Public License 2.0
57 stars 26 forks source link

Unable to deploy correctly #423

Closed goevexx closed 4 years ago

goevexx commented 4 years ago

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 : 

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender (file:/C:/Users/nmo/.vscode/extensions/redhat.vscode-server-connector-0.22.1/server/bin/felix.jar) to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

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 use test_project as base directory.

The server configuration looks like this:

{
  "args.override.boolean": "true",
  "id": "wildfly-18.0.0.Final",
  "id-set": "true",
  "org.jboss.tools.rsp.server.typeId": "org.jboss.ide.eclipse.as.wildfly.180",
  "program.args.override.string": "-mp \"C:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\modules\" org.jboss.as.standalone --server-config=standalone.xml Djboss.server.base.dir=C:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\test_project",
  "server.home.dir": "C:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final",
  "vm.args.override.string": "\"-Dprogram.name=JBossTools: dealmapBayBG\" -server -Xms64m -Xmx512m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true \"-Dorg.jboss.boot.log.file=c:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\test_project\\log\\boot.log\" \"-Dlogging.configuration=file:c:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\\test_project\\configuration\\logging.properties\" \"-Djboss.home.dir=c:\\Users\\nmo\\.rsp\\redhat-server-connector\\runtimes\\installations\\wildfly-1800finalruntime\\wildfly-18.0.0.Final\" -Dorg.jboss.logmanager.nocolor=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se -Djboss.bind.address.management=localhost",
  "wildfly.publish.restart.pattern": "\\.class$|\\.jar$",
  "deployables": {
    "d:\\dev\\project\\Portal": {
      "label": "d:\\dev\\project\\Portal",
      "path": "d:\\dev\\project\\Portal",
      "options": {
        "option": {
          "deployment.output.name": "Portal.war"
        }
      }
    },
    "d:\\dev\\project\\SimpleWarehouse": {
      "label": "d:\\dev\\project\\SimpleWarehouse",
      "path": "d:\\dev\\project\\SimpleWarehouse",
      "options": {
        "option": {
          "deployment.output.name": "SimpleWarehouse.war"
        }
      }
    }
  }
}

Java Version:

openjdk 11.0.3 2019-04-16 LTS
OpenJDK Runtime Environment Corretto-11.0.3.7.1 (build 11.0.3+7-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.3.7.1 (build 11.0.3+7-LTS, mixed mode)

Any suggestions?

lstocchi commented 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?

goevexx commented 4 years ago

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?

robstryker commented 4 years ago

I'll look into this.

robstryker commented 4 years ago

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.

robstryker commented 4 years ago

See for example https://github.com/redhat-developer/vscode-rsp-ui/issues/103

robstryker commented 4 years ago

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.