On 23/05/2010 04:57, buddhika chamith wrote:
Hi All,
It seems that o.a.Catalina.Core MBeans descriptor has got operations
containing POJO objects instead of primitive types which make them
inaccessible via JConsole.
I suggest the following to avoid this situation. Any comments and
suggestions are appreciated.
*Class: StandardContext *
'
Method : addValve (org.apache.catalina.Valve)
Suggestion : Modify the signature to addValve(String className) where
className is that of the Valve to be instantiated. This is acceptable since
all the Valve classes have no arg constructors AFA I noticed.
Method : removeValve(org.apache.catalina.Valve)
Suggestion : Modify the signature to removeValve(String oname)
I wouldn't modify these methods, I would add new ones - probably to
ContainerBase along the lines of:
addValve(String oname)
removeValve(String oname)
That way, you can use the MBean Factory to create and register the valve
and the oname to add it to a component. I haven't confirmed this but it
should be do-able.
Methods :
add/removeLifecycleListener(org.apache.catalina.LifecycleListener)
Suggestion : Remove the methods since the method can be provided in a
generic way with only involving primitives. Any ideas on this?
I don't understand what you mean here.
These methods can be included in a seperate MBean class
(e.g:StandardContextMBean) so that original class interface is left intact.
Ah. The method changes above make more sense now. I'm not sure about
this. My instinct is to prefer not to have a separate class as that is
one more thing to keep in sync. I can see how it would be useful. I
think this is a case of needing to look at both options and deciding
which is best.
*Class: StandardEngine*
Method : addChild(org.apache.catalina.Container)
Suggestion : addHost(String name, String appBase, boolean
autoDeploy,boolean deployOnStartup,boolean deployXML, boolean unpackWARs)
This method can be included in a seperate MBean class so that original class
interface is left intact. Since only a host can be added as a child mbean
method name can be named as addHost to remove any ambiguity.
*Class: StandardHost*
Method : addChild(org.apache.catalina.Container)
Suggestion : addContext(String path, String docBase, boolean
xmlValidation, boolean xmlNamespaceAware, boolean tldValidation, boolean
tldNamespaceAware)
*Class: StandardService*
Method : addConnector(org.apache.catalina.connector.Connector)
Suggestion : addConnector(String address, int port, boolean isAjp,
boolean isSSL)
Same comment as above re separate MBean classes vs methods using oname.
*Class: StandardWrapper*
Method :
add/removeLifeCycleListener(org.apache.catalina.LifecycleListener)
Suggestion : Remove the methods since the method can be provided in a
generic way with only involving primitives.
Again, I don't get what you mean here.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
