[EMAIL PROTECTED] wrote:
> On Thu, 6 Jun 2002, Christopher K. St. John wrote:
>
> > This sounds a bit like o.a.commons.modeler. (modeler
> > provides code to fill in MBean meta-data based on an external
> > xml file, see o.a.catalina.mbeans.mbeans-descriptors.xml)
> >
> > Is the magic jk code related, a replacement, or just something
> > completely different?
>
> I am well aware of modeler, I mentioned few times I think it is
> a good solution but not the best ( at least for our use case ) :-)
>
> Modeler creates model MBeans, based on a XML config file.
>
> This solution uses Dynamic MBeans, using introspection data -
> at least at the first level. It'll probably use some XML
> ( or properties file ) similar with modeler, but automatically
> generated from javadoc tags ( @jmx:attribute, etc ) and source.
>
> The big difference is that with model MBeans, the JMX implementation
> is providing the bridge between JMX callers and the actual managed
> bean.
>
> With dynamic MBeans, our Dynamic proxy gets called and we
> can save/manipulate the data.
>
> If users sets "port" to "8081", we can save this info in
> our representation of config ( I'll try to use something similar with
> preferences for <1.4 and preferences in 1.4 ).
>
> The result is that we can manage the config file based on what is
> actually set by user, not on data extracted from the runtime.
> ( we can also insert the very usefull ${substitution} and many
> other tricks ).
+1
Maybe we can add for admin to handle dynamic user added components later too.
:-)
Amy
>
>
> A second difference is that we need to also manage the C components,
> i.e. provide the same JMX interface for mod_jk. Again, a dynamic
> mbean is essential for this - it'll probably do some AJP calls
> in setAttribute(), etc.
>
> Costin
>
> --
> 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]>
