On 4/4/12 12:49 PM, ssilvert(a)redhat.com wrote:
On 4/4/2012 1:36 PM, Brian Stansberry wrote:
> I can definitely see how this would be useful though.
>> Now a tool can let the user choose subhandlers by finding all the
>> instances of custom-handler and file-handler. It then presents a pick
>> list of the handlers it found. The tool doesn't need any special
>> knowledge about handlers. It just knows how the list is defined and
>> acts accordingly. All the UI logic can be generated from the resource
>> description.
>>
>> And when you go to delete a handler, the management model will know that
>> an async handler has subhandler references pointing to it. So, it thows
>> an exception.
>>
> That's not the case, as the referent does not know what all refers to
> it. For example, there's no way socket-binding=* can know from its own
> static metadata what all the other resources are that might refer to a
> socket-binding. Some custom subsystem yet to be written by an end user
> may refer to it. The server itself needs to track that at runtime.
Yes, I was assuming that the server would keep track of the references.
So once a reference value is put into the model the referent will be
notified that someone is referring to him. The action taken when a
referent is deleted could be defined in the resource that contains the
reference. I guess the actions would be values like NO_OP, REMOVE_ME,
and THROW_EXCEPTION.
Gotcha.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat