>How about assuming that Watchdog watches URLs, not Files, just >URLs. HTTPWatchdog makes that assumption, why not have FileWatchdog >make it as well? You can always convert a file:// type URL to a >java.io.File. Moreover, the openStream method of java.net.URL can be >used to convert a URL to an inputStream.
This works for FileWatcher and HTTPWatcher, but why limit it to what happens works for these watchdogs? I don't know if this is a good/possible thing, but what if you wanted to create a watchdog that watched a socket to get configuration data, SocketWatchdog. SocketWatchdog has an independent thread that writes data from the socket into a buffer. SocketWatchdog checks the buffer periodically to see if any data has been written to the buffer. If it has, it returns the current time to indicate that there is an update. When asked for the config data, it returns an InputStream to the buffer data and maybe even the socket itself. In this case a url is not sufficient and doesn't make sense, does it? Like I said, I don't know if this particular case is practical, but I think it makes my point. There may be cases where a URL doesn't make sense. Substitute a JMS topic for the socket/buffer, JMSWatchdog. Does a URL make sense? >IMHO, InputStream is more basic than a URL not more generic. That is the better way to say it, yes. Because InputStream is more basic than URL, to me, it seems like a medium that should be supported at the same level as URL. It also does not place limitations on the Watchdog that the watched element is the source of the configuration data, which is sort of implied by requiring a single URL. It is also possible for a watchdog to be written that might read from multiple sources for configuration data, not a single url. Maybe this is a bit far flung, but it leaves the options up to the developer. The watchdog will support whatever specific properties are needed to configure it (ie file name/url, url, socket info, multiple files, jms topic, whatever), and the getConfigurationStream() method handles/hides the details. I think the same could be said for configuration data sources in general, which is why I suggested doConfigure(InputStream) be added to the Configurator interface. It could be useful beyond the Watchdog case. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
