[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3073: ------------------------------------ I believe this is the server object caching the runtime location instead of drawing from the runtime directly. Use case: Create Runtime / Server Change Runtime Location Verify: Server still points to old location -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3073: ------------------------------------ The server has those other paths in case your runtime is in /apps/jboss4.2 and your deploy directory is in /home/max/deployments. One of the two paths listed in the editor is the ultimate deploy folder, the other is the temporary deploy folder. The temporary deploy folder should be used so that the final "move" from temporary location to final location occurs from two paths on the same file system. Since your deploy folder can be anywhere, even if its not underneath your app server / runtime, then the temporary folder must also be global. These paths should be global since its possible that even after moving a runtime, you want your deploy folder and your temporary deploy folder to remain the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Max Rydahl Andersen reopened JBIDE-3073: ---------------------------------------- When I follow the usecase (i.e. change the location of the runtime) then the server still starts the server in the old location. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker updated JBIDE-3073: ------------------------------- Summary: Change runtime and server still starts from old location (was: Servers are created with hardcoded paths instead of relative to the runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3073: ------------------------------------ I can come up with a fix for this... however... it will remove some user choice in customizing their launch configuration. Currently, I set up the defaults upon creation. After that, I don't really keep much in sync. The user can change whatever they want to the launch config. They can change the working directory, the classpath, etc. They have complete control. If I add this change, then the vm arg java.endorsed.dirs will *always* be linked to the runtime, no matter what the user tries to do to change it. The working directory will *always* be linked to the runtime even if the user tries to change it. And the classpath will (attemptedly) always be linked to the server. Also, the Tomcat server suffers from a bug which I see no around if I do what's being suggested. The bug is that the proper jars are added to the classpath, (user entries, run.jar). If the runtime is changed, all I can do is *add* a new entry. The bug specifically is that if you modify the runtime's location, a new entry is added but the old one remains. So you effectively have two entries of the same jar in different folders. My other option is to remove all other entries, but if the user has added something custom to his classpath, this will ruin that and the user may complain that "i just added 10 things to my classpath, then changed my runtime, and all 10 are gone!". Clearly we'd like to avoid this. The question is, what trumps? Keeping the launch config in sync with the runtime? Or allowing users ultimate control over their launch config? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3073: ------------------------------------ Yes I can set "default" command line args and vm args without storing them in the launch configuration, however, once the user CHANGES them or ADDS to them, it must then be stored in the launch configuration. And if they THEN change the home location of their runtime, then it will blow up. Example: 1) Create runtime 2) default arguments prevail, nothing is stored in launch config 3) User adds a -Dsome.custom.param=blah to the vm args. VM args are now stored *in* the launch config 4) User modifies runtime's home address. Custom, modified, stored-in-the-config arguments are NOT updated. Maybe then the user changes his -b to be customConfig, while his runtime is actually config=default. Stuff is not in sync, user has no idea which one to change, tooling launches the server with -b = customConfig but THINKS the config is default since that's the config stored in the runtime object. The Tomcat server adapter forces certain fields to match the runtime... No matter what the user does. I think this is a good way to do things. Certain fields *must* match the runtime. The users are still able to add and remove arguments that the adapter doesn't concern itself with, however a few special arguments (configuration, bind address, etc) are modifiable only by changing the runtime or changing in the server editor... NOT in changing the launch config. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-3073?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-3073: ------------------------------------ For QA: 1) have two jboss 4.2.2.GA (or any specific version) installations 2) Make a runtime / server combo out of installation 1 3) click "open launch configuration", verify arguments include "--configuration=default" and vmargs include -Djava.endorsed.dirs="/home/rob/apps/jboss/jboss-4.2.2.GA/lib/endorsed" (or something similar) 4) Double click server, click "runtime environment", modify runtime location to second install, change configuration to "all", press finish 5) DO NOT SAVE. Click "open launch configuration" 6) verify command line arguments now say "--configuration=all" and vmargs include -Djava.endorsed.dirs="/home/rob/apps/jboss/jboss-4.2.2.GA_INSTALLATION2/lib/endorsed" (or something similar) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira