[jbosstools-dev] Question on Good Practice Re: Servers and Runtimes

Rob Stryker rob.stryker at redhat.com
Tue Jan 13 13:57:37 EST 2009


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.



More information about the jbosstools-dev mailing list