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 ).
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]>
