> >By doing this we could create a subclass which would use introspection to
> >list all attributes and operations, for objects that want to be beans and
> >just what to expose all publics.
> >
>
> I see how this could be simpler in some cases... But in cases where you are
> using interface Inheri
> >But once there is a common abstract to sub-class or a concreate wrapper
> >(that would proxy to an object), that seems like it would be easier than
> >the
> >interface as well as provide more functionality.
>
> No, I think that the easiest way to expose attributes and functions is to
> list the
> >Why not? Aren't DynamicMBeans easier to work with? I am actually a little
> >confused about the different types, short of the basic MBean that
> >implements a mgmt interface.
> >
>
> NO they are harder to implement. A dynamic MBean has to explicitly export
> all of it's managment interface.
On Tue, 14 Aug 2001, Hiram Chirino wrote:
> I was looking for a way to fill in those description fields that
> DynamicMBeans can fill out. But I did not want to have to replace all the
> JBossMQ MBeans with DynamicMBeans. So this is what I did:
Why not? Aren't DynamicMBeans easier to work with
