On 07/11/2007, at 7:15 PM, Curt Arnold wrote:
On Nov 7, 2007, at 1:55 AM, Curt Arnold wrote:
Okay, I'm about ready to fall over, but I looked at zeroconf and
see your motivation for moving the binding onto the main thread so
you continue the set up in
ZeroConfSocketHubAppender.activateOptions. However instead of
changing the behavior, I'd be more inclined to make a few changes
to SocketHubAppender to make it more amenable to extension but keep
the old behavior. I'd suggest:
Moving ServerMonitor out to a separate public class.
Move the self-start in ServerMonitor to
SocketHubAppender.startServer.
Make SocketHubAppender.startServer protected and overload it in
ZeroConf.
Add a protected SocketHubAppender.stopServer and move the
ServerMonitor.stopMonitor code there.
I'd suggest that you not take code suggestions from me too seriously
this late at night. There is probably a cleaner way to be able to
provide a hook for the zeroconf registration code to run. Maybe
adding like adding
protected void socketBound(ServerSocket s) {
}
notification method to SocketHubAppender and then hook it at
ZeroConfSocketHubAppender to publish the address.
Before I forget (currently in the middle of quartely software release
week.. extremely overloaded, I'm not ignoring this..), yeah I agree
with this approach. I'd be tempted as part of the separation to
introduce a standard Java Listener interface and have socketBound and
socketAccept callbacks while where there.
I'm not exactly sure when I'll get to it though, this week is going to
be busy. May not be till Friday.
cheers,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
