We can't start and stop a remote server - hence we got the deploy only server. Going forward I want these to server types to be merged.
With respect to the paths how do you want us to deploy if not by copying the files ?
JBoss 5.1 will hopefully give us a remote deploy function.
Let me know what you expected to happen ?
The following is what I instinctively assumed it would do, but I guess it makes for a good 5.1 *wish list*. I understand now that it is much more than what the current capabilities do.
1) Ability to start, stop, and to some extent monitor what the remote server does - provided the user is authorized to do so on the remote server. (Probably not realistic for 5.1)
2) Using an exposed filesystem for the move to the temporary folder (as today) is fine (although an FTP or HTTP upload would be less restrictive).
3) Using 'something' on the server so that the move from TMP to Deploy folders happens locally on the server (instead of being done through the developer's PC filesystem).
All of the above should be implementable fairly easily by putting some secured web services on the server and calling them from the jBossTools plugin. It would give you excellent flexibility while preserving control and security. It would also free you from any dependencies from the underlying network and filesystem.
Just a thought. Keep up the good work.
1) Any suggestion on how we should be able to start a remote server ? (restarting, monitoring and stopping is doable - but starting I can't see how we should be able to do that.
2) Could be done with Eclipse's virtual filesystem support - though for AS 5.x we would probably use the profile manager since it got support for remote deployment, but for systems where we cant do that remote copy via ftp/http could be an option.
3) Not sure what you mean here ?
1) I see that it is difficult to do remote Start since you have nothing that you can be sure is listening. In Unix servers you might be able to use SSH as a way to access the remote server. I am not sure about windows.
3) I meant:
3a) Admins are likely to expose 'a folder' to the network (where the temporary copy from developer's PC to server computer can happen).
3b) Admins are NOT likely to expose the 'deploy' folder to the network. Most will flat out refuse, citing security reasons.
3c) If 3b is the case, only a process running on the server computer can move the file, because processes running on the developer's PC cannot see that folder.
3d) A web service would allow executing the move from temporary to deploy folder, since the process would be running on the server computer and have access to both folders. Any other mechanism that executes the move using the CPU of the server would work just as well.