avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: BlockListener and LifecycleHelper
Date Sat, 17 Nov 2001 13:27:17 GMT

Peter Donald wrote:
> On Sat, 17 Nov 2001 00:16, Stephen McConnell wrote:
> > I want LifecycleHelper to invoke component lifecycle phases
> > on a listener.
> right. I don't mind LogEnabled but I don't like any of the others ;)
> > You objected to this because you said that
> > listener logic should reside in a block.
> I said there was no such thing as listener logic. Listeners are
> just glue to stick together blocks appropriately ;)

And I said that happended to by your use-case, not mine :-)

> A while back I sent a lick to an article on javaworld.

I bet that was a suprise for the Editor :-)

> The articule basically discussed the separation between
> "procedural" and "declarative" parts of a system. Can't seem
> to find think at the moment ...
> Blocks are definetly the procedural part of the system. They do things.
> I see listeners as the delacarative part. Essentially they manage
> rules such
> as
> * "All SOAPable Blocks are exported via a SOAPServer Block"
> * "All Blocks are managed by MyManager Block"
> * "All Persistable Blocks are persisted by MyPersistentManager Block"
> * "All RMIEnabled Blocks are exported by MyRMIExporter Block"
> * "All Repository Blocks are registered with all Store Blocks"
> * "All ... Blocks are ... by ... Block(s)"

What your decribing here is "one-potential-set-of-semantic" that a
listener may have.  That set of semantics is much more fine-grained
than the listener interface itself.  It is also a set of semantics
that has nothing to do with my application case.

> 1-to-1 listeners may also be viable and this is essentially the
> reason why I allow Configuration for Listeners.
> So Listeners still == Gaffer tape for Blocks ;)

For your use-case, not mine!

> > I objected to that
> > because I have "application" level logic that does not belong
> > in a block - it belongs in the listener. I think we both
> > agree that when logic is exposed to blocks, this done through
> > a block acting as a proxy to the listener.
> no - I definetly dont agree with that ;)

I'm not going to explore this one.

> Blocks provide the logic and may interact/provide services to
> other blocks.
> Listeners are only enablers of block interaction.
> > What we apparently
> > don't agree on is allowing a listener to be a component (i.e.
> > has a lifecycle covering contextualization, composition,
> > initialization, dispose, etc.
> coposition can't be done as there is no notion of dependencies.
> initialization shouldn't really be done as no listener should be
> allocating any significant resources (same reason for KB'ing
> dispose)

Agree - I should not have included compose (my mistake).  Let me
outline the "component" interface that I want to see support
for and the reasons why:

   LogEnabled - If I'm logging anything within an object that's
     declared as a listener, I don't want to have to set-up
     another logger - just want to be supplied automagically

   Contextualizable - this one is a little tricky - the code
     I have is doing validation of the environment before blocks
     kick in - validation needs the information about the
     application context (available under the application meta-data
     receivable under contextualization of a listener).  To veto
     start-up, I need to be in application space (no block space)
     because I can throw an exception and halt/suspend start-up.
     There are alternative such as extending the embeddor but this
     means creating a different Phoenix which I want to avoid.

   Configurable - I'm holding my application policy here.

   Initializable - Because I'm following Avalon component
     pattern and this is the trigger to start working and I don't
     like changing that without having some tangible

   Disposable - arguments are the same as initalize.

> > I need to understand why your objecting to that.
> Put it this way. I see listeners as not doing any logic - they are
> declarative constructs for establishing relationships. I want to know why
> this will not work in your case.

1. because I am NOT wiring blocks together
2. because I don't have an alternative mechanism
3. because I object to assertion that the current listener declaration
   is a valid "declarative constructs for establishing relationships"
   (it only references a class name within the scope of the application
   and declares nothing about relationships)
4. because I'm dealing with application policy
5. because I'm stubborn and you haven't given me a good tangible
   technical argument why this is inappropriate
6. because I wanted to have a least six bullet points

> So far you have only indicated that you
> "want" to do logic in listeners. I want to know why the listeners as
> declaratives model doesn't work in your case or makes it harder
> to construct your application. So far I haven't seen any indication that
> this is so ;)

I'm handling application level policy.  The registration of a listener
is the only access point I have to plug-in an application-level facility.
is a different use-case to yours - but that does not make it invalid - just
different.  All I'm proposing is that IF a class, registered as a listener,
exposes any of the above component interfaces, then, give the class what it
needs to do its stuff correctly.

Cheers, Steve.

> --
> Cheers,
> Pete
> ---------------------------------------------------------
> Clarke's Third Law: "Any technology distinguishable from
> magic is insufficiently advanced".
> ---------------------------------------------------------
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message