Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <406D76D7.7060801@anyware-tech.com>
Date: Fri, 02 Apr 2004 16:21:11 +0200
From: =?ISO-8859-1?Q?C=E9dric_Damioli?= <cedric.damioli@anyware-tech.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CocoonTask
References: <406A9162.3050007@anyware-tech.com> <406A9563.4070009@upaya.co.uk>
 <406A9F9A.4070603@anyware-tech.com> <406D58E3.1070707@anyware-tech.com>
 <406D6B1D.7070701@upaya.co.uk>
In-Reply-To: <406D6B1D.7070701@upaya.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Upayavira wrote:

>> C�dric Damioli wrote:
>>
>>> Upayavira wrote:
>>>
>>>> C�dric Damioli wrote:
>>>>
>>>>> I'm wondering if there's any reasons why there's no access (via 
>>>>> protected method or fields or whatever) to the CocoonBean.
>>>>
>>>>
>>>> Basically, the CocoonBean is invoked via reflection, using a 
>>>> different classloader. Now, I'm no reflection expert, and calling 
>>>> each getter and setter one at a time using reflection seemed 
>>>> unreasonably complex. So, I chose to create a Delegate class, 
>>>> invoke that with reflection, and have that do the real work. 
>>>
>>>
>>> I'm ok with the concept of "single entry point", but what I wanted 
>>> is the possibility to act on the CocoonBean before processing the 
>>> different uris.
>>> Imagine you have a Java method returning a Collection of uris to be 
>>> processed, you may want to directly fill the CocoonBean with this 
>>> Collection, instead of dynamically re-creating the CocoonBean 
>>> configuration. 
>>
>>
> So you're saying that you've got code running in other Ant tasks, and 
> that Java code wants to make collection data available to the 
> CocoonTask? How would it get there? Could you include a sample of the 
> code that your CocoonAntDelegate would use? 


The AntDelegate I currently use is basically like :

public process (Document xconf, String uriGroup, 
org.apache.tools.ant.Project project)
{
        CocoonBean cocoon = new CocoonBean();

       // Adding some target URIs, coming from anywhere (database, Ant 
properties, environment, ...)
       cocoon.addTarget(...);

       // Adding some listeners
       cocoon.addListener(...);

       BeanConfigurator.configure(...);

        cocoon.initialize();
        cocoon.process();
        cocoon.dispose();
}

I see the AntDelegate as a bridge between Ant and Cocoon worlds : it is 
why I included the Project as third argument. But I think it's not 
enough : the AntDelegate could be extensible, and become a "real" class 
(not only with a single static method), or even an interface with the 
current AntDelegate as a default implementation.

BTW, i don't see why you used an OutputStreamListener as last argument 
of BeanConfigurator.configure()
IIUC, the OutputStreamListener mixes two roles : a role of 
DefaultListener (logging to stdout) and a role of reporter (generating a 
report for broken-links), actually used by the BeanConfigurator. May 
this Listener be split into two : a DefaultListener and a 
BrokenLinksListener ?

>
>
>>>>> I wanted to use it directly to add BeanListeners, eventually add 
>>>>> targets, and so on...
>>>>
>>>>
>>>> What sort of listeners would you like to add? If you want to 
>>>> specify a different listener, I would suggest coming up with a 
>>>> generic way to specify listeners and add that to the 
>>>> BeanConfigurator, so that all users of the CLI and Ant task get to 
>>>> benefit. 
>>>
>>>
>>> I wanted to add org.apache.cocoon.bean.BeanListener implementations 
>>> to my instance of CocoonBean.
>>> The problem with adding this at BeanConfigurator level is that we 
>>> can't interact with the Ant Project (or its Properties), for 
>>> example, or whatever is not directly tied to the Bean.
>>
>>
> Sorry, I don't understand. What do you mean that you can't interact 
> with the Ant project? You can use Ant properties in the Cocoon task. 
> Are you looking for a greater integration? 

Let me give an example :
I have a Java class able to retrieve somewhere (in a DB with JDBC, or in 
a XML file, ...) a list of uris to be processed by the CocoonBean.
I have to instanciate this class, set some parameters and finally asking 
it for the URIs list.

I'm not an Ant expert, but I think it would be hard to do it easily in 
pure Ant. With my new AntDelegate, it's very easy.

>
>
> I think you're getting at something here. What I'd like to see is the 
> Ant task using Ant's methods and approaches to configure itself, 
> rather than using Java - putting your code into Java can hide it, as 
> far as the Ant script is concerned.
>
>>>>> IMHO, the best way to "open" the CocoonTask is to allow subclasses 
>>>>> to change the delegate class 
>>>>> ("org.apache.cocoon.bean.helpers.AntDelegate" at the moment) and 
>>>>> to give this delegate access to the calling Ant project.
>>>>
>>>>
>>>> So you supply a piece of java that configures the bean before 
>>>> running? Hmmm, I would much rather extend the xconf format to be 
>>>> able to add everything you want. The CocoonTask really should not 
>>>> assume any Java knowledge in its users. 
>>>
>>>
>>> Of course, but I think that the xconf format is already very 
>>> complete for users who do not want to write any Java code : all the 
>>> setters of the Bean have their counterparts in the xconf format 
>>> (except the addBuildListener). The next step would be to add a 
>>> syntax to add Java entry points (such as  : <listener class="..."/> 
>>> or <configurator class="..."/>) but users of such a syntax would 
>>> have to write Java code anyway.
>>>
>>> What I proposed is to have the possibility to extend the CocoonTask 
>>> (or the AntDelegate, or both) to provide access to users (such as me 
>>> :-) ) who want to have more control over the Bean.
>>
>>
> I'm okay with that, but I'd like to see if it is possible to keep that 
> sort of configuration out of Java, until really necessary.
>
> I'd love to see ways of dynamically creating your list of URIs, and a 
> range of other bean listeners that do other things, other than the 
> default one, etc ,etc. 

I have written a few.
The Ant script containing my Cocoon Task is running in a separate Thread 
and executes periodically. The execution may take many hours. I have 
written a BeanListener which stores the current state of the build : 
number of pages currently processed, stats on their contents, ..., so 
that a user connected to the monitoring page may follow the build.

>
>
> Regards, Upayavira
>
>
C�dric