> |2. The org.jboss.configuration.ConfigurationService mbean now registers all
> |mbeans loaded from the jboss.jcml configuration file with the
> |ServiceControl mbean.
> |There is no requirement that an mbean implements the
> |org.jboss.util.Service interface.
>
> ... hmmmm .... you are saying that when someone registers with us he doesn't
> need to implement the interface?
An org.jboss.util.Service interface must be passed to the ServiceControl mbean
on registration. All that has changed over the previous solution is that we aren't
requiring that the mbean implement the Service interface, but someone must.
>
> |The Service interface used to register the jboss.jcml mbean with the
> |ServiceControl mbean is obtained either from the implementation of the new
> |org.jboss.util.ServiceFactory interface specificed via the new
> |serviceFactory
> |jboss.jcml mbean tag attribute,
>
> So you can register ANY Service interface? what is the point of the SC
> then... does it do any call?
>
Were talking about the org.jboss.util.Service interface still. All the SC does
now is maintain an ordered list of Service instances and it invokes the
init/start/stop/destory methods in the registration order on these as before.
Now it is invoking through a Service interface rather than the MBeanServer.
>
> |or by a dynamic proxy that determines
>
> I can't make sense of the sentence... the dynamic proxy is from where
> JDK1.3? and it generates a proxy that can call the interface you pass, but
> what interface? I understand from the part below that you are talking about
> the MBean itself, do you mean dynamic proxy in the 1.3 DynamicProxy
> sense?...
>
Yes, proxy in the sense of java.lang.reflect.Proxy +
java.lang.reflect.InvocationHandler.
> |which if any of the init/start/stop/destroy methods the mbean
> |implements using
> |introspection of the mbean operations. The latter is used in the absence of
> |a non-empty serviceFactory attribute.
>
> ah a default, I like that.. so if I don't bother with all this, the proxy
> determines what calls are offered by the MBean that just registered
>
> well, you know me, if you code you code, so it goes in, but frankly it means
> the integration is very heavy now... very heavy, a new class factory, a new
> jcml tag, a new default... it is also programmatic... pfffffffffff and what
> did we gain? an integration where brits can choose to not implement
> interfaces of management? ;-)
>
> Frankly I am not sure I like this...
>
By default it is still simple and lightweight. There has been a proxy introduced
but this simply ensures that if an mbean only had a couple of the Service
methods in its mbean interface we are no longer invoking the unimplemented
methods. So for example, the com.sun.jdmk.comm.HtmlAdaptorServer mbean
only implements start()/stop() and now these are the only methods the dynamic
proxy attempts to invoke on the mbean. Previously init() and destroy() were
invoked as well as the resulting exception silently ignored.
The addition to the jboss.jcml DTD is a serviceFactory attribute, not a tag so
unless you want to use the new factory mechanism its a noop that behaves
exactly as before except that methods that are not implemented are not invoked.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
