Huw,
In effect you are suggesting that we need not bother with interfaces suffixed with MBean? You are saying that with markup tags only, you can generate dynamically a JMX presence for a Phoenix hosted app?
Yes - basically instead of looking at the interface to determine what methods to export, it uses the tags instead.
I'm all for that, if true. By code breakage you mean, through avalon-apps etc?
The only way removing the MBean interfaces will break anything is if some client code takes special action based on the *MBean class. For example, client code might do a check to see if a managed object is an instance of ApplicationMBean and then use that fact to decide what to display.
Also, I'm not removing support for this functionality, I'm just changing it in phoenix to what i consider the 'standard' (simpler) pattern.
There are two ways to expose management information now:
1) use the phoenix-mx tags to markup blocks/apps/components as management-enabled and then specify the methods and attributes to export
2) have the class implement a management interface (usually called *MBean), and pass that into the export() method
Method 2) is supported, but at least in my opinion, no longer the best way to go. Can I remove them and then mark-up the base classes with the management info? Or will that break a lot of code?
If its a problem, I can markup the MBean interfaces instead. The result is the same, I just think less classes is better if we can get there.
- Huw
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
