This is a common problem; fundamentally, you might think of the bridge objects as existing in
many places at the same time – most
significantly, they exist both on the bridge AND in conferences; or, to state it inversely,
they remain on the bridge, even when
they are in a conference.
The most common manifestation of this is reception of duplicate events when the application
uses generic, top-level listeners, instead of
using the specific event listener functions provided. The following snippet illustrates a
common (but incorrect) means of listening
for children on the Connection object.
Snippet illustrating the creation of a "generic" ChildListener on the
Connection
/* ... */
public class
GlobalChildListener
extends ChildListener
{
@Override
void childAdded( ChildEvent event )
/* ... */
@Override
void childRemoved( ChildEvent event )
/* ... */
}
/* ... */
public class
Application
{
Connection bridge ;
GlobalChildListener bridgeSpy ;
/* ... initialise ACP-API connection ... */
bridge.addChildListener( bridgeSpy );
/* ... */
}
/* ... */
When this application adds an EndPointListener to Conference
objects (as in the snippet below) it will start to receive
duplicate events. This is because the EndPoint and Conference
objects are children of the Connection,
whilst the EndPoint is also a child of the Conference.
Snippet illustrating adding the EndPointListener to the
Conference object
/* ... */
public class
GlobalChildListener
extends ChildListener
{
@Override
void childAdded( ChildEvent event )
{
if( event.getChild() instanceof Conference )
{
Conference c = (Conference)event.getChild() ;
c.addChildListener( new GlobalChildListener() ) ;
}
/* ... */
}
/* ... */
}
/* ... */
This is further exasperated when we introduce the *PropertyChangeListeners which
monitor property changes on child objects.
The solution is to manage where and how the application listens for changes; specifically,
the application should use the add listener functions
(e.g. addConferenceListener, addEndPointListener) wherever
possible, rather creating generic child listeners. It is thus
implied that listening for EndPoint objects on the Connection is
discouraged (because there is no function for it) and
by extension, the application should addConferenceListener, and then
addEndPointListener to those Conference
objects. The following illustrates the recommended implementation.
Snippet illustrating correct use of listeners for Conference and
EndPoint objects
/* ... */
public class
EndPointListener
implements com.avaya.conferencing.api.acp.control.events.ConferenceEndPointListener
{
@Override
public void
childAdded( ChildEvent addEvent )
{
/* ... do something to endpoint upon arrival in conference ... */
}
/* ... */
}
/* ... */
public class
ConferenceListener
implements com.avaya.conferencing.api.acp.control.events.ConferenceListener
{
@Override
public void
childAdded( ChildEvent addEvent )
{
addEvent.getChild()
.addEndPointListener(
new EndPointListener() ) ;
}
/* ... */
}
/* ... */
public class
Application
{
public static void
main( String args[] )
{
Connection bridge ;
/* ... connect to bridge ... */
bridge.addConferenceListener(
new ConferenceListener() ) ;
/* ... */
}
}
Last Release: 6.2 SP6 (Sept 2018)
