You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2002/05/24 06:38:09 UTC

[myrmidon] TaskListener.contextualize()

Hi,

I was wondering whether we should add a method such as "contextualize()" to 
the TaskListener interface. This would allow TaskListeners to read propertys 
out current PropertyStore and all that sort of thing. 

I think I will add it in now - but what do you think - good idea or bad idea?

The main thing it is useful for is that listeners could read "environment" 
proeprtys from TaskContext and log appropriately.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [myrmidon] TaskListener.contextualize()

Posted by Peter Donald <pe...@apache.org>.
On Tue, 28 May 2002 13:27, Adam Murdoch wrote:
> > > > I think I will add it in now - but what do you think - good idea or
> > > > bad idea?
> > >
> > > Seems like a good idea.  See how it goes.
> >
> > Turned out not to be so good. The question became which TaskContext do
> > you use?
>
> You'd use the context for the execution frame that the listener is being
> added to.  Which in the case of adding listeners from the command-line,
> would be the root execution frame (which the embeddor maintains).

that could work I guess.

> > No matter which "scope" you used it never seemed to make sense. Not
> > sure how we get configuration data from command line to TaskListener. I
> > am reluctent to use setters as most listeners will not be able to be
> > configured by a limited number of parameters.
>
> Running the listeners through a configurer might be the best bet.  This
> would handle listeners added from the command-line, from a config file, and
> from a task, all using the same config mechanism.

So some of the commandline options get translated into attributes of 
ModelElement and a generic entry point may also be added. You could also load 
config from file or whatever - I like !

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [myrmidon] TaskListener.contextualize()

Posted by Adam Murdoch <ad...@apache.org>.
On Fri, 24 May 2002 15:34, Peter Donald wrote:
> On Fri, 24 May 2002 14:50, Adam Murdoch wrote:
> > On Fri, 24 May 2002 14:38, Peter Donald wrote:
> > > Hi,
> > >
> > > I was wondering whether we should add a method such as
> > > "contextualize()" to the TaskListener interface. This would allow
> > > TaskListeners to read propertys out current PropertyStore and all that
> > > sort of thing.
> >
> > What would get passed to contextualize()?  A TaskContext?
>
> Yep.
>
> > > I think I will add it in now - but what do you think - good idea or bad
> > > idea?
> >
> > Seems like a good idea.  See how it goes.
>
> Turned out not to be so good. The question became which TaskContext do you
> use? 

You'd use the context for the execution frame that the listener is being added 
to.  Which in the case of adding listeners from the command-line, would be 
the root execution frame (which the embeddor maintains).

> No matter which "scope" you used it never seemed to make sense. Not
> sure how we get configuration data from command line to TaskListener. I am
> reluctent to use setters as most listeners will not be able to be
> configured by a limited number of parameters.

Running the listeners through a configurer might be the best bet.  This would 
handle listeners added from the command-line, from a config file, and from a 
task, all using the same config mechanism.

When adding listeners from the command-line, the config model would be built 
from some common command-line options (eg --loglevel, --logfile, etc), plus 
maybe some custom listener attributes (eg --listenerparam name=value), maybe 
merged with the contents of a listener config file (eg --listenerconfig 
somefile.xml).

When you're adding listeners from a config file or a task, you'd use an inline 
model from the file or task model.

Maybe rather than trying to do anything too complicated from the command-line, 
we should look at getting config files working instead, and use them for 
configuring the listeners.

-- 
Adam

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [myrmidon] TaskListener.contextualize()

Posted by Peter Donald <pe...@apache.org>.
On Fri, 24 May 2002 14:50, Adam Murdoch wrote:
> On Fri, 24 May 2002 14:38, Peter Donald wrote:
> > Hi,
> >
> > I was wondering whether we should add a method such as "contextualize()"
> > to the TaskListener interface. This would allow TaskListeners to read
> > propertys out current PropertyStore and all that sort of thing.
>
> What would get passed to contextualize()?  A TaskContext?

Yep.

> > I think I will add it in now - but what do you think - good idea or bad
> > idea?
>
> Seems like a good idea.  See how it goes.

Turned out not to be so good. The question became which TaskContext do you 
use? No matter which "scope" you used it never seemed to make sense. Not sure 
how we get configuration data from command line to TaskListener. I am 
reluctent to use setters as most listeners will not be able to be configured 
by a limited number of parameters.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [myrmidon] TaskListener.contextualize()

Posted by Adam Murdoch <ad...@apache.org>.
On Fri, 24 May 2002 14:38, Peter Donald wrote:
> Hi,
>
> I was wondering whether we should add a method such as "contextualize()" to
> the TaskListener interface. This would allow TaskListeners to read
> propertys out current PropertyStore and all that sort of thing.

What would get passed to contextualize()?  A TaskContext?

> I think I will add it in now - but what do you think - good idea or bad
> idea?

Seems like a good idea.  See how it goes.

-- 
Adam

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>