When using Management Beans in Java, its interface is exposed through MBean Interface. But if there are various parameters to be exposed through MBean. And with different version of the system, many new parameters might be added or subtracted from the MBean, then it becomes very tedious to manage such system.
Is there any design pattern that can be used to avoid such problems ?
If you want things to happen dynamically, you've got to have some logical rule to dynamically determine which fields \ methods of the managed class should be exposed and which should not.
Now, you might be able to implement a Dynamic MBean (see a great explanatory example here) and use reflection to gather up-to-date information of the managed class. The reflected class info should then be filtered against the previously mentioned rule (hoping all other programmers follow it! I wouldn't count on it).
OK, so this isn't a design pattern. I think the real recommended pattern is that the programmer that adds certain property should take the few moments reasoning whether it is worth exposing and whether it is safe to be exposed. And when removing a property, one should think whether it doesn't break any exsiting client code out there.