Re: CocoonTask

[Cédric Damioli <ce...@anyware-tech.com>]

Upayavira,

Any thoughts about this ?
Or do you prefer that I come up with a concrete proposal ? :-)

Cédric


Cédric Damioli wrote:

> Upayavira wrote:
>
>> Cédric Damioli wrote:
>>
>>> Hi,
>>>
>>> I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant 
>>> build script. 
>>
>>
>>
>> Great. I'm glad to hear you're using it. 
>
>
> I'm actually running Cocoon in a servlet, which periodically executes 
> an Ant build script ending with the CocoonTask :-) Seems complex, but 
> is really effective !!!
> And your work on the CLI is great and very appreciated ;-)
>
>>
>>
>>> 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.
>
>>> 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.
>
>>> 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.
>
>>
>>
>> Regards, Upayavira
>>
>>
> Cédric
>

Re: CocoonTask

[Upayavira <uv...@upaya.co.uk>]

Cedric,

Two thoughts:

1) Why do you use Ant for this? Why not just have your own class that 
invokes the bean? Then you can do what you like.
2) Your idea of splitting the OutputStreamListener into DefaultListener 
and BrokenLinkListener is a good idea. It might be a bit slower, but it 
would be much clearer. I'd happily receive a patch on that one.

Upayavira

Cédric Damioli wrote:

> 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
>
>
>

Re: CocoonTask

[Cédric Damioli <ce...@anyware-tech.com>]

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

Re: CocoonTask

[Upayavira <uv...@upaya.co.uk>]

Cédric Damioli wrote:

> Upayavira,
>
> Any thoughts about this ? 

Yes. I started thinking, it got complicated, and then forgot to finish 
thinking. Sorry!

> Or do you prefer that I come up with a concrete proposal ? :-)

Not yet.

> Cédric Damioli wrote:
>
>> Upayavira wrote:
>>
>>> Cédric Damioli wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant 
>>>> build script. 
>>>
>>> Great. I'm glad to hear you're using it. 
>>
>> I'm actually running Cocoon in a servlet, which periodically executes 
>> an Ant build script ending with the CocoonTask :-) Seems complex, but 
>> is really effective !!!
>> And your work on the CLI is great and very appreciated ;-) 
>
Thanks.

>>>> 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?

>>>> 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?

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.

Regards, Upayavira