Currently, server and runtime objects in wtp have "names", the displayable value, and "ids", the value in their serialized file which links together the various pieces. In the past, I used the WTP default of a timestamp-type "id", and assigned names to the server and runtime objects. But it was discovered that doing that made it almost impossible to "share" this server object in a repository. The server would reference some vague timestamped runtime, and it would be impossible to create a runtime of that timestamp really. So I switched to having the name and the id be exactly the same. The side effect of this is that, when you change the runtime or server's name, you're changing it's "id" also, and so by changing a runtime's name, any server's that link to it now point to a not- found runtime. This is in addition to any projects that referenced that runtime. This is very related to JBIDE-3391, where the user changed the runtime's name from within the server editor, but then did *not* save the dirty server editor to update the reference. This broke his deployment, and though the JIRA doesn't mention it, the user would actually not be able to re-open the server editor =P Admittedly this issue is the user's fault as he didn't save the dirty server editor... but if he had changed the runtime's name from the runtime preference window, instead of the editor, there'd be no recourse *at all*. ALL the servers and projects would reference a stale nonexistent runtime object. Since the default Runtime id is a timestamp-like string, it assumes that you can change the name all you want, and that doing so will not create stale objects. But months ago we decided we liked having names as our id instead of random timestamp strings. I'm honestly not sure what to do here. It's obvious to me that the id must be an unchanging string and a timestamp is as good as any... Look forward to input. _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

WTP allows adopters to change the id and the name, if they want. Most adopters (apache, generic server, etc) do *not* change the id, but rather leave the id with the timestamp string. This, of course, makes copying a server file into your workspace to create the server impossible because the odds of having a runtime with the same timestamp id are close to zero. max.andersen(a)redhat.com wrote: > What does wtp do ? > > /max (sent from my phone) > > > On 13/01/2009, at 07.00, Rob Stryker <rob.stryker(a)redhat.com&gt; wrote: > >> Currently, server and runtime objects in wtp have "names", the >> displayable value, and "ids", the value in their serialized file >> which links together the various pieces. >> >> In the past, I used the WTP default of a timestamp-type "id", and >> assigned names to the server and runtime objects. But it was >> discovered that doing that made it almost impossible to "share" this >> server object in a repository. The server would reference some vague >> timestamped runtime, and it would be impossible to create a runtime >> of that timestamp really. >> >> So I switched to having the name and the id be exactly the same. >> The side effect of this is that, when you change the runtime or >> server's name, you're changing it's "id" also, and so by changing a >> runtime's name, any server's that link to it now point to a >> not-found runtime. This is in addition to any projects that >> referenced that runtime. >> >> This is very related to JBIDE-3391, where the user changed the >> runtime's name from within the server editor, but then did *not* >> save the dirty server editor to update the reference. This broke his >> deployment, and though the JIRA doesn't mention it, the user would >> actually not be able to re-open the server editor =P Admittedly >> this issue is the user's fault as he didn't save the dirty server >> editor... but if he had changed the runtime's name from the runtime >> preference window, instead of the editor, there'd be no recourse *at >> all*. ALL the servers and projects would reference a stale >> nonexistent runtime object. >> >> Since the default Runtime id is a timestamp-like string, it assumes >> that you can change the name all you want, and that doing so will >> not create stale objects. But months ago we decided we liked having >> names as our id instead of random timestamp strings. I'm honestly >> not sure what to do here. It's obvious to me that the id must be an >> unchanging string and a timestamp is as good as any... >> >> Look forward to input. >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev