[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: draft Java-api-12



Steven Sonntag wrote:

> Rob Weltman wrote:
>
> > Steve Sonntag wrote:
> >
> >>  I have been thinking about the specification forunsolicited
> >> notifications in the Java api draft version 12. The draft has two
> >> methods in LDAPConnectionthat are concerned with Unsolicited
> >> Notifications: one sets a flag indicating whether to keep or
> >> discardunsolicited notifications:
> >> setUnsolocitedNotifications(boolean flag)the other gets the value of
> >> the flag Unsolicited notifications are retrieved by callingthe
> >> getResponse(0) method from one of theListener classes.  the "0"
> >> indicates message ID 0. The problem is that a listener has
> >> association witha connection only when a request is in progressusing
> >> that listener.  A listener in an application with5 connections open
> >> could be servicing requestson all five connections or on none of
> >> them.  UsinggetResponse from the listener class to getUnsolicited
> >> notifications is problematic.  If no requestsare outstanding on the
> >> listener, there is no associationwith a connection, so it is not
> >> possible to checkfor unsolicited notifications. It would seem that
> >> the only reliable way to check forand get unsolicited notifications
> >> would be throughthe LDAPConnection class itself and not through the
> >> listener.classes. Two more LDAPConnection methods - ugh, butperhaps
> >> necessary? Anyone have any better ideas? -Steve
> >> ------------------------
> >> Steve Sonntag
> >> Novell, Inc., the leading provider of Net services software
> >
> >
> >   It might be better instead to eliminate the current unsolicited
> > notification methods and instead have methods to add and remove
> > listeners for usolicited notifications. The implementation can then
> > discard unsolicited notifications if there are no listeners. For
> > example (I haven't thought this through completely yet):
> >
> > LDAPConnection
> >
> > public LDAPResponseListener addUnsolicitedNotificationListener(
> > LDAPResponseListener listener )
> >
> > public void addUnsolicitedNotificationListener( LDAPResponseListener
> > listener )
> >
> > Rob
> >
>
> I like your idea Rob, it fits much better with the rest of the
> architecture.
>
> I have a few questions:
>
> Are multiple UnsolicitedNotificationListeners allowed on a given
> connection.
> What would the behavior be in such a situation.  The name seems to
> indicate
> that multiple are allowed.
>
> My take is that only one unsolicited notification listener exists for a
> given connection.
> Of course, that listener may be servicing multiple connections (using
> the first method
> to create it).  I am not sure of the purpose for the second method.
> Would the first method be more clearly named
> "setUnsolicitedNotificationListener",
> implying there is only one?
>
> I assume that getResponse() blocks if no unsolicited notifications are
> available.
>
> getMessageIds would return an array with 0 being one of the message ID
> values.
>
> Could this listener be merged with a regular listener?  There seems no
> reason why it
> couldn't.
>
> How does one remove an unsolicited notification listener, or was your
> second
> method meant to be a delUnsolicitedNotificationListener?

  Yes, except it should be:

public void removeUnsolicitedNotificationListener( LDAPResponseListener listener )


  I was thinking that you could have more than one listener - that's why the method naming (also, of course, to be consistent with the JDK's listener method naming). An implementation could feed each listener with a copy of each incoming unsolicited notification, and each client could pull out notifications independently.

Rob