"rgrzywinski" wrote:
If attributes are populated -before- create(), what possible benefit is there in even having create() (over, say, start() (except that start() may be called multiple times))?
Why are the attributes added before creation? Is there a dependency reason?
Has any thought been given to adding an attribute to the <attribute> tag so that the attributes can be added after creation?
Having the attributes set before create() is forcing me to move initialization to the constructor.
The sequence for MBean initialisation goes:
1. constructor - usually do nothing
2. attribute configuration - just setters
3. create() - e.g. aquire resources, expose a reference of your service
4. start() - in service
So attribute set is really the equivalent of a constructor with arguments. However, since they are JMX attributes they can be set later on (e.g. using the JMX-console). Now, when an MBean is started, setting its attributes may have no effect at all for many services, unless they are coded to monitor the setter and do something.
Having 2 step for starting (create() / start()) may seem redundant but it solves some chickent-and-egg problems. E.g. two MBeans that need to have a reference of each other. How would you do this with a single start(). The first MBean to start() would not find the 2nd one. But now is possible with:
1) 1st MBean create() - expose your reference (e.g. register with some Naming Service, JNDI, MBeanServer, whatever)
2) 2nd MBean create() - do the same
3) 1st MBean start() - find the reference of the 1st MBean, usually store it, for referencing while in normal operation
4) 2nd MBean start() - do the same.
For most case though, only the create()/destroy() or start()/stop() pair is coded.
There is no reason to move initialisation within the constructor, (you can do it during create() which mean your attributes are configured by the time is called). In a sense, create() becomes your constructor.
Regards
/Dimitris
