[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