https://issues.apache.org/bugzilla/show_bug.cgi?id=49045
--- Comment #1 from chamith buddhika <chamibuddh...@gmail.com> 2010-04-04 06:24:32 UTC --- Created an attachment (id=25228) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25228) Adding createStandardService method to MBeanFactory This initial version of the patch adds createStandarService method. However I am having some issues with the usage of the MBean with respect to MBeanFactory. In the case of MBeanFactory both the managed resource and the associated MBean are MBeanFactory instances. But only resource MBeanFactory object is properly populated with a reference to the Server in its container field. The associated MBean instance which gets registered in the MBean Server (created by JMX infrastructure) doesn't get populated with this field since it is being created using reflection in createMBean() method in ManagedBean class. Now when the MBean createStandardService method is invoked using JMX (which depends on container field being properly set - in this case the reference to the single Server instance) the MBean and not the managed resource is invoked causing a null pointer exception. The below code snippet in BaseModelBean causes the above behaviour. // Invoke the selected method on the appropriate object Object result = null; try { if( method.getDeclaringClass().isAssignableFrom( this.getClass()) ) { result = method.invoke(this, params ); } else { result = method.invoke(resource, params); } } Here as can be seen the precedence is given to the MBean object instead of the associated resource object. Can somebody comment on the reason for the above logic? To get the resource MBeanFactory instance invoked I have included a check as follows in the above condition which I think is not the way to go. if( method.getDeclaringClass().isAssignableFrom( this.getClass()) && !method.getDeclaringClass().equals(this.getClass()) ) { Any ideas on this issue? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org