[ http://jira.jboss.com/jira/browse/JBIDE-699?page=comments#action_12371688 ] Max Andersen commented on JBIDE-699: ------------------------------------ I do not understand ;) Could you please explain the steps that I need to do to cause this error ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-699?page=all ] Gail Nagle updated JBIDE-699: ----------------------------- Attachment: JBOSS_AS_40.launch This is an example of the launch file that is produced by the JBOSS_AS server and is used to start the JBOSS server inside Eclispe. It would be nice if this were shareable and reuseable after the import of the Server Project into a workspace. Currently it is not and has to be recreated in each workspace by every team member. Not very efficient. Also, when things change, every member of the team must be notified to make the change instead of simply doing an svn update and getting what is needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-699?page=comments#action_12374838 ] Gail Nagle commented on JBIDE-699: ---------------------------------- I apologize for not seeing that I needed to attach my documentation to this page. I am new to JIRA. I have added the additional documentation you requested. To summarize, the problem is that my team needs to be able to share JBOSS AS launch configurations. It takes a lot of time to set these up. We are working on individual VMs and need to be able to store these in svn so others can use them. The main issue is that we need to be able to use variables to specify the path to various external jars that are needed by JBOSS to run our applications. The interesting thing is that after importing the Server project, the launcher plugin "sees" the existing launch since it will not let you create a new server of the same name. But IT WILL NOT RUN THE EXISTING LAUNCH config from the imported server. The attachments show screen shots that demonstrate the problem. It takes multiple steps so if you need further clarification, you can call me today between 1:30 and 5:30 PST and I would be glad to explain the problem further. 858-675-1922. I hope this helps. Please do not close this as it is vital to our use the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-699?page=comments#action_12377713 ] Rob Stryker commented on JBIDE-699: ----------------------------------- There really isn't a way to do this the way you want, Gail. I'm going to try to be as descriptive as possible, but still, it doesn't look good. The reasons are as follows: 1) Nothing is stored in the workspace's Servers project. That project is there for tomcat and other server types. We do not use it at all. 2) The "Configuration path" listed in the server editor (double-click the server) is supposed to point to Servers\someFolder where our server *would* store server-specific items... but we don't. Again, that's a folder we don't use. So of course you're wondering, why can't we just store the launch configuration there? The code that associates a server with a launch configuration is not in JBoss Tools or RHDS. but rather inside "Eclipse Webtools Project (WTP)". Now you're going to say you already asked eclipse about it, and you did, but you asked the part of eclipse concerned with generic uses of launch configurations. Looking at the eclipse bug, they solved the idea of importing launch configurations, in a general sense, and it can now be done. However, the bunch of code that's preventing you from re-using launch configurations in this fashion is in Eclipse Webtools. In Eclipse Webtools, each "Server" object is associated *directly* with a launch configuration. The creation of a server *automatically* creates its launch configuration. It's a 1-1 mapping. This isn't our structure that's preventing it, it's Eclipse WTP. The Common tab of the launch configuration only says where to save it; WTP still prevents the user from using that file for a new server. New servers, again, automatically create their own launch configuration. I could, conceivably, try to change this into a feature request to allow you to point to another launch configuration, but there are some more issues. Basically, to launch a server, eclipse WTP looks through all the launch configurations it can find until it finds one that matches launch type *and* has a parameter that links it to the current server. An example is: <stringAttribute key="server-id" value="9_19_07_4_37_PM1"/> That wierd value is actually the server ID. That value is actually generated by a timestamp of when the server was created. This means that even if you did manage to share, and then add, the shared configuration into the launch manager, you'd need to manually change the server-id attribute of the launch configuration to the one of your newly created server. This is because there's no way to tell the server an ID it should take, and I'm very sure that sharing a "Server" would be *extremely* difficult, what with all the different places server information is stored. Server objects are serialized in a number of places and sharing that would just be near impossible. --- So each server makes its own launch configuration right away. There's no way to tell the server upon creation that it should use some other configuration, so the only option is to create a new server, then *overwrite* the launch configuration hidden deep in the bowels of the debug.launch workspace metadata, but make sure you *don't* overwrite the server-id value so that it links up with your local server and not some other. Yes, this seems very restrictive. But this is the structure of eclipse WTP. The best I can do is turn this into a feature request to allow you to designate another launch configuration as a delegate, but this simply won't be something available any time soon at all. I'm really sorry, Gail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-699?page=comments#action_12412655 ] Rob Stryker commented on JBIDE-699: ----------------------------------- This issue may have a workaround in wtp 3.0 (and thus future versions of jboss tools). Just wanted to ping. I'll get back to here after verifying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira