I want to talk about something else that I think might be related to this
eventually, but I have a couple of comments.
>The argument about multiple input sources is unconvincing because
>while a URL might be insufficient an InputStream is not either.
I can write my own custom InputStream whose implementation concatenates a
series of InputStreams from files, urls, whatever. Not really possible with
URL.
>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.
Did you mean "...don't think it is possible..."? I'm not sure I follow this
statement otherwise.
>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.
If you think that all configurators cannot support InputStream, than this is
a problem, yes. I see what you are saying about URL being richer than an
InputStream. I guess I am questioning whether only having a
doConfigure(URL) in the configurator is sufficient for all cases. I think
there can be cases where I have an InputStream, but no URL. Because
InputStream is more basic, I feel it is more likely a configurator can
support InputStream than URL. I'll have to see if I can explain myself
better.
But, I want to change the subject slightly. Talking about the other
mythical implementations of Watchdog, SocketWatchdog and JMSWatchdog, got me
thinking about the design. I am thinking that there can be at least two
different models for getting reconfiguration data:
passive - These are the current crop of Watchdogs, FileWatchdog &
HTTPWatchdog. They require a configured interval to check an element
periodically to see if reconfiguration should be performed.
active - These are a different crop of Watchdogs. These watchdogs are not
configured with an interval. The reconfiguration data is "pushed" to them
via some kind of messaging mechanism. The reconfiguration data just shows
up as part of a listener/notification pattern. I was thinking that the
socket and jms examples would fall into this model.
I am ignorant on the specifics of jms, but I have a little more experience
with sockets. You might implement a SocketWatchdog that does something like
this:
ServerSocket ss = new ServerSocket (listenport);
while (running) {
// accept the connection from my client
Socket sc = ss.accept();
// grab the output stream of the socket
// and use it to reconfigure
reconfigure(sc.getInputStream());
}
This is different than the current Watchdog implementation. A modification
date is meaningless. An interval is meaningless. You might not even
consider it a "watchdog" as the data is pushed, not watched.
Can someone tell me if there is some similar mechanism for jms? How would
it work? I am going to look it up for myself, but any expertise would be
appreciated.
So, I was thinking of renaming my Watchdog implementation to
AutoReconfigurator. It is a mouthful, but I can't think of anything else at
the moment. A synopsis of the design/inheritance would look like:
AutoReconfigurator.java
AutoReconfiguratorBase.java
PassiveAutoReconfigurator.java
FileAutoReconfigurator.java
HttpAutoReconfigurator.java
...
ActiveAutoReconfigurator.java
SocketAutoReconfigurator.java
JMSAutoReconfigurator.java
...
AutoReconfigurator.java - An interface that defines all methods common to
all AutoReconfigurators: get/setName, get/setConfigurator, start, stop.
AutoReconfiguratorBase.java - An abstract implementation of
AutoReconfigurator interface that provides implementations for the simple
methods like get/setName, get/setConfigurator. Would also implement a
protected method of reconfigure(InputStream) that would provide code to
access the configurator for all the subclasses. Methods like start and stop
would still be abstract.
PassiveAutoReconfigurator.java - An abstract subclass of
AutoReconfiguratorBase that also implements Runnable. Implements the start,
stop, and run methods in a fashion suitable for passive type
reconfigurators. Introduces abstract methods getModificationTime and
getInputStream. Implements methods for get/setInterval,
get/setModificationTime.
FileAutoReconfigurator.java & HttpAutoReconfigurator.java - Specific
subclasses of PassiveAutoReconfigurator. Much like the current
implementations.
ActiveAutoReconfigurator.java - An abstract subclass of
AutoReconfiguratorBase that also implements Runnable. Implements the start,
stop, and run methods in a fashion suitable for active type reconfigurators.
Not sure what specific methods would be required, still thinking about it.
SocketAutoReconfigurator.java & JMSAutoReconfigurator.java - Specific
subclasses of ActiveAutoReconfigurator. Mythical at this point.
It might be easier to follow the above with some source files. I started
working on them last night, but have not finished them. I would appreciate
any feedback people might have on the above design. Do you think the
differences between passive and active are artificial? Maybe one design can
accomadate both?
I am also thinking that in the active model, a url doesn't make much sense.
The data is generally given, most likely as an InputStream. Thus my earlier
comments regarding doConfigure(InputStream).
-Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
