>>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?
In the SocketWatchdog case, a URL remains appropriate. For example, we could use the URL.openStream() method to get the InputStream. In summary, a URL is an InputStream enriched with meta data. Regarding JMS, an InputStream is inadequate to represent a JMS channel whereas a URL might be enough for addressing information. >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. The argument about multiple input sources is unconvincing because while a URL might be insufficient an InputStream is not either. In any case, since a URL is richer than an InputStream, I don't think it is impossible to argue that a given Watchdog would work if doConfigure(InputStream) was available whereas doConfigure(URL) is insufficient. >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. There is a difference. In the case of PropertyConfigurator and DOMCOnfigurator it was trivial to add the doConfigure(InputStream) method. However, if we add this method in the Configurator interface, it makes it mandatory for all Configurators. Regards, Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
