The problem is the MBean instance, not the attribute value and requiring the MBean implementation to be Serializable is not realistic. I'm not finding a clear statement of why the AttributeChangeNotification should use the MBean instance as the source of the notification sent out vs the ObjectName, which seems preferrable as you do not enter into this dance of deciding what the type of source is depending on what layer is dealing with the notification.

The MBeanServer impl imposes a org.jboss.mx.server.NotificationListenerProxy which unconditionally overwrites the callback notification source with the ObjectName the listener is interested in. The HAServiceMBeanSupport can do the same as the sender must be the 'this' service.

  public void sendNotification(Notification notification)
  {
    try
    {
      notification.setSource(this.getServiceName());
      sendNotificationRemote(notification);
    }
    catch (Throwable th)
    {
      boolean debug = log.isDebugEnabled();
      if (debug)
        log.debug("sendNotificationRemote( " + notification + " ) failed ", th);
      // even if broadcast failed, local notification should still be sent

    }
    sendNotificationToLocalListeners( notification );
  }

--
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx

Ivelin Ivanov wrote:

I implemented tests and example classes, which work in clustered
environment,
but they were apparently using serializable objects.
I was thinking that it would be sufficien to document this requirement.
How can "this" be replaced with ObjectName generically by
HAServiceMBeanSupport?

-=Ivelin=-




------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to