> > public void register(Object key, Object value) throws
> >RegistrationException;
> >
> > public void deregister(Object key) throws RegistrationException;
> >
> Object keys are better yes. Note that the actual soapification api
> changed to allow a list of interfaces to expose (via DynamicProxy).
> Lets say that one (arguably poorly written) block implemented 10
> interfaces, but only a couple were to be exposed for internet presence
> of the object, then you'd want to specify the subset n'est pas?
both the MBean generator and soapification service provide this:
soapification:
// relevant part of interface:
void publish(Object obj, String publicationName, Class[]
interfacesToExpose)
throws SOAPificationException;
void publish(Object obj, String publicationName, Class
interfaceToExpose)
throws SOAPificationException;
void publish(Object obj, String publicationName)
throws SOAPificationException;
// somewhere:
SOAPification soapifier =
getService("org.apache.avalon.cornerstone.services.soapification.SOAPificati
on");
soapifier.publish(obj1, "key1");
soapifier.publish(obj2, "key2");
mbean:
// relevant part of interface:
public static DynamicMBean create( Object obj )
throws NotCompliantMBeanException;
public static DynamicMBean create( Object obj, MBeanInfo mBeanInfo )
throws IllegalArgumentException, NotCompliantMBeanException;
public static DynamicMBean create( Object obj, Class[] interfaces )
throws IllegalArgumentException, NotCompliantMBeanException;
// somewhere:
MBeanServer mbeanserver = getMBeanServer();
MBean bean1 = DynamicMBeanFactory.create( obj1 );
MBean bean2 = DynamicMBeanFactory.create( obj2 );
mbeanserver.registerMBean( "key1", bean1 );
mbeanserver.registerMBean( "key2", bean2 );
as you can see, the process is remarkably similar.
We have 3 options as I see it:
a) make the options mostly identical and provide 'universal management'
at the 'avalon level';
b) make an MBeanServerImpl wrapping SOAPification and adapt SOAPification
to provide all the functionality required by the JMX spec and provide
'universal management' at the 'JMX level';
c) not care about the difference.
option a would make the functionality avalon-specific. Option b warrants
a separate project ("Apache JMX") providing a JMX implementation that
also supports SOAP. Option c is not cool.
I think option b is best; unfortunately, it is also the most work. So I
suggest we try (a) first.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]