anonymous wrote : Random without some stable alias is not useful for debugging.
Is this in reference to the concept discussed on JBMESSAGING-1121 of using a GUID?
Re: getting the data from ServerConfig, etc., sounds good to me. That gets into where the
metadata comes from / how services consume it. My immediate concern is what the metadata
*is* -- who needs what, and in what form. Assumption being that if end users are somehow
or other going to have to configure this, we should make their lives as easy as possible
by trying to settle on a single base piece of information. Maybe services massage that
base information or allow per-service overrides, but there is just one base value.
My original post on this thread stated that the integer id JBM was using "isn't
really appropriate for the jvmRoute or HAPartition use cases." I don't know why
I wrote that; can't think of any reason why an integer is inappropriate. mod_jk may
force us to prefix the id with some string to make a jvmRoute, but that's no big deal
to work around (e.g. in a workers.properties file 'worker.0.port=8009' *might* be
an issue but 'worker.node0.port=8009' is fine.)
At this point the known use cases are:
1) JBM -- an id is required and must be an integer (unless Tim decides otherwise).
2) JBossWeb -- id only required when JK is used. Integer is OK, minor preference that
it's not a really long one.
3) HAPartition. Required for a marginal use case of preventing a node joining the cluster
twice. Integer is OK.
Anything else? What about JON?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098998#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...