Where can I find current instructions for how to set up Remote Debugging of Wildfly 20 from Eclipse 2020-06? My searches have found posts going back to 2014 they don't work. My most recent attempt is to follow https://tools.jboss.org/documentation/howto/configure_remote_server.html. This has no date on it and it is for connection to EAP 6.1 instead of Wildfly 20 but at least it is from tools.jboss.org and the instructions matched Eclipse 2020-06.
The problem is that when I right click on on the new Server just created with these instructions and select Debug I get the following error:
failed to copy to /opt/wildfly-20.0.1.Final/standalone/deployments/MyApp.war/META-INF/MANIFEST.MF on host 192.168.1.19
The requested path is not found on the remote system.
Here are what I think are important facts:
The path /opt/wildfly-20.0.1.Final/standalone/deployments DOES exist on the Wildfly 20 server # 192.168.1.19.
The Wildfly 20 server is started with /opt/wildfly-20.0.1.Final/standalone/deployments/MyApp.war in place. The Management console shows that MyApp is Deployed and I can access the app from a remote machine so Wildfly and the server are running.
I can connect from Eclipse to the Wildfly server using the Remote Systems item that creating the new Server created. In particular, I can use the root item to "roam around" the file system on the Wildfly server so that suggest to me that Eclipse can establish a connection to the Wildfly server.
The instructions in the URL above did not include this but in the Server's Properties the Web and Management ports were both 0. I manually set them to 8080 and 9990 respectively.
Thank you in advance.
Since your installation is on /opt I guess it was done with root privileges. I'm not sure your user has sufficient rights to be able to access those paths.
As far as I can tell /opt is the recommended installation location but I finally got the server to at least deploy so that problem is solved. See updated question at Attempt to debug a remote Wildfly 20 server failing.
I am configuring Wildfly server in eclipse(STS). While configuring, I noticed the following option:
Server is externally managed. Assume server is started.
What does this option do ?
Does it impact capability of hot deployment of jsps etc.
Can someone also point to a location where all these options are described in detail for Wildfly server configuration in eclipse?
"The Server is externally managed. Assume server is started" field is used when the user wants to deploy the server but does not want the IDE to stop or start the server for them. Depending on the requirements, select this check box or leave it unchecked, as is default.
http://tools.jboss.org/documentation/howto/configure_remote_server.html
Our application deployed in mule server has credentials in properties file that are used to access Database and other cloud. We have to do some change in properties file. I would like to know whether this will require a redeployment of the running application or it would be sufficient to restart the application from mule managent console or a server restart may be required.
Any suggestion would greatly help.
Thank you in advance
I believe you can still control the applications from MMC, even when they are deployed using the $MULE_HOME/apps directory. You navigate to them through the "Servers" tab. Find the application under the server, and there is an option at the top right to "Stop" and "Start" the application. This should allow you to run with the new configuration values.
The simplest possible without restarting your Mule Server is to Redeploy the application from the Mule Management Console (Deployment tab).
Hope this helps.
I have managed to get Eclipse Juno connecting to the internet. For this to accomplish, there are many posts here on stackoverflow. here is one of this links:
Eclipse not connecting to internet via proxy
Today i installed Eclipse Kepler on my Windows7 box. But accessing the eclipse marketplace or installing new software does not work.
I am using exactly the same proxy configuration as i used for Eclipse Juno. Juno can access the marketplace but Kepler does not.
The proxy uses NTLM Authentification.
Any one here with similar problem?
No success til now. I am still wondering why Juno can connect whereas Kepler can not:-(
I had same issue. I searched and found this.
http://oakgreen.blogspot.jp/2011/10/eclipse-proxy-settings-bug-and.html
This post says don't set SOCKS proxy. I tried this advice, and connection was succeeded.
I did below:
Open Network Connection Settings.
Select Active Provider to "Manual".
Set HTTP/HTTPS proxy.
Clear SOCKS proxy if this is set.(select SOCKS proxy row and click "Clear" button)
Restart Eclipse to apply these settings.
I spent hours trying to use this method suggested by mhanada and although it is correct and should have worked the default Secure Storage associated with eclipse was preventing my proxy credentials from being saved. I advise: Be wary of exceptions being thrown regarding Secure Storage. In my case the errors related to being unable to connect to a remote location where the default secure storage path was. In my case I just deleted the Default Secure Storage information via Preferences > General > Security > Secure Storage > Contents > Delete.
In my case I set it to "native" settings where socks was enabled for proxy. (Internet Explorer->Internetoptions->Connections->LAN-Settings->Proxy Settings). After disabling it there and adding the following lines to eclipse.ini everything works well:
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.closeTimeout=3000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=3000
In my case the problem started after installing the Spring Tool Suite. Uninstalling it solved the problem.
Version: Kepler Service Release 1
A friend of mine ran into that exact problem (fresh machine with a fresh eclipse Kepler installation, the computer was not behind a firewall or proxy.) It turned out to be an issue with Java 7 update 51, when we used a Java 6 JRE to run eclipse the problem was magically solved.
Another note:
After changing my Windows password, eclipse's Windows-integrated secure storage seemed to have become inaccessible without notice. Apparently this not only made eclipse 'forget' my proxy auth settings but also prevented it from storing the credentials after I set them up again. I could configure them any way I wanted but as soon as I clicked "OK" they were gone again.
The solution for me was to go to General > Security > Secure Storage and click on "Change Password..." for the Windows Integration master password provider. Of course, this wiped all passwords previously stored by eclipse, but it left me with a clean, working Secure Storage and allowed me to successfully set up and store the proxy credentials again.
I had faced the same problem , The issue with my set up was I was using JDK, after repointing to JRE it is working perfectly now.
Proxy Setup- Windows->Preferences->General->Network Connections.
Active Provider-Native, Just make sure HTTP - Dynamic should be checked, remaining all should be Unchecked.
Note: Above Description Tried and tested with Kepler only.
It happened to me because eclipse was using JRE and not JDK.
To force eclipse to use a given VM, edit
<eclipse_root>\eclipse.ini
and add those 2 lines at the top of the file:
-vm
C:/Program Files/Java/jdk1.6.0_45/bin/javaw.exe
Note:
Eclipse using JRE was triggering a:
java.lang.NoClassDefFoundError: javax/net/ssl/SSLSocket
java.lang.NoClassDefFoundError: javax/net/ssl/SSLSocket
at org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(SchemeRegistryFactory.java:45)
at org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:294)
at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:445)
at org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:274)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:797)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:263)
at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLSocket cannot be found by org.apache.httpcomponents.httpclient_4.1.3.v201209201135
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:455)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(Unknown Source)
Did you make sure that you selected the Manual mode in the Active Provider section? Go to the Preferences/General/Network Connections menu again and change that if it is not. I think that part is kind a buggy.
I had this issue, and i changed the proxy settings with password in eclipse.
go to windows-> preferences-> search for "proxy"
open Network connections.
Select Active Provider to Manual.
Set HTTP and HTTPS proxy, system username and password.
(it was not working without username and password in my machine)
Clear SOCKS proxy if its set.
File-> Restart
A strange problem occurred yesterday on a production system which has been running fine for weeks on a JBoss 4.2.3 application server: the JAR file containing the web application was no longer in the deployment folder (so the clients could no longer access the application). The server is running on a Windows box.
There was no indication of undeployment in the server logs. Normally JBoss detects if somebody deletes (or moves) a deployed web application file and executes the standard undeployment procedure, so there would be a log entry in this case.
Other web applications on the same system continued to run fine, so it was only this JAR file which simply disappeared.
Has somebody seen a similar problem with web applications on JBoss?
I'd bet my shoes that's not possible to happen spontaneously.
Check your security settings - didn't you leave JMX console accessible? Etc.