Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 9 Aug 2011 12:10:13 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Monitoring iterative algorithms
Message-ID: <20110809101013.GV18819@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=K4w@mail.gmail.com>
 <4E4049F2.3040109@gmail.com>
 <CAGRH7HpxeW8GkLkWRKnfTj8kL64E_2waJB0THuPvQbRT-PQELQ@mail.gmail.com>
 <4E40E199.3070006@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E40E199.3070006@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: hel 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at hel
X-Virus-Status: Clean

> >> +1 to the idea of using the Observer pattern; but -0 for
> >> Observable.  I would favor defining Events and Listeners because a)
> >> Observable is concrete, so effectively forces you to create an
> >> Observable delegate
> >>
> > I'm not sure I understand. Components in java.awt also need to
> > implement quite a few methods like addListener, fireEvent, and so on.
> > Maybe we could write a DefaultObservable, which would implement most
> > of the methods required by Observable, and could be inherited by some
> > (probably not all, unfortunately) of the already implemented iterative
> > algorithms ?
> 
> I was suggesting that we dispense with having anything inherit from
> Observable and just define events and listeners, similarly to what
> you find in the awt components, but also elsewhere like javax.sql or
> javax.servlet (and I am sure lots of other places too).  Observable
> just gives you hasChanged and a primitive, non-type-safe
> notifyListeners.  To do proper event propagation you need to define
> custom events anyway and register listeners, so unless all you need
> to raise are "some state has changed" events (like what a GUI
> presentation layer needs from the model in MVC), you are better off
> implementing a proper event framework.  This does not have to be
> heavyweight.  Just define
> 
> 0) Event class(es) extending j.u.EventObject
> 1) a listener interface extending j.u.EventListener
> 2) implement addXxxListener, removeXxxListener and
> fireInterstingEvent1...n in the class that you want to be observable
> (i.e. source events)

I don't object that it would be more elegant or type-safe but this is
already more than the one method that would need to be delegated
to an "Obervable" instance stored in the class to be monitored.

For the kind of monitoring that is envisioned here (i.e. call the monitor
after each iteration, I feel that the direct/simple/crude approach may be
enough: It would use a standard class, it might be sufficient for
S�bastien's current need, it would be fairly easy to implement.
Later on (4.0), we can always switch to a more featureful monitoring setup.

> Items 0) and 1) and most of 2) are going to be necessary anyway if
> you want to propagate typesafe events.  All that you really save by
> bringing in Observable is maintenance of the listener collection,
> which is trivial.

As I don't know anything about JMX, I have no idea of what it would take to
get to a workable proof-of-concept, i.e. something which we can test with
various classes that could be monitored, so that we can be convinced that
the design is fine.
This additional work-load is a consequence of not willing to depend on
external libraries.

Is there someone willing to work on this, i.e. search for similar tools, and
duplicate the work so that CM can continue to not depend on other libraries?

I also think that before embarking on the monitoring issue using concepts
like "Event", "Listener" and JMX, it might be wise to (re-)discuss a
seemingly less complex but related issue issue: logging.
Depending on the conclusion reached on that topic, the approach to the other
issue might be different.

> [...]


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org