cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: Cocoon resource publishing
Date Fri, 20 Jun 2003 08:24:25 GMT
 
> > So I think I do need to hold on to the idea of using the 
> same Cocoon 
> > instance for publications wich means that if I were to use 
> CocoonBean 
> > I'd also need a way for the HTTP servlet to work with that, or at 
> > least share the Cocoon instance it uses. Is there a way to 
> accomplish 
> > that?
> 
> I don't see why the bean couldn't be instantiated with a 
> cocoon instance:
> 
> CocoonBean bean = new CocoonBean(cocoon);
> 
> or something like that. So long as the bean code can handle 
> both possibilities.

I think the alternative constructor would do it definitely. Although I
would miss all the functionality that CocoonBean provides for creating
and initializing Cocoon.

> 
> > I also noticed that there is some state associated with CocoonBean 
> > that prevents it from being shared among clients. So 
> although there is 
> > a lot of functionality there I'm not sure how to use it in this 
> > multi-threaded multi-client situation.
> 
> The bean started as (and still pretty much is) a simple 
> separation of the CLI Main.java class into two parts. So it 
> doesn't think at all in terms of multi-threaded environments. 
> However, I don't see why it couldn't be improved.
> 
> What 'state' are you referring to?

I mean state that controls the way processing is done such as
followLinks flag and state that holds information about a single
processing run such as the brokenLinks List for instance.

I'm wondering whether we should split up CocoonBean into a class for
creating and setting up Cocoon and one that holds all the code related
to a single run. The former would follow a singleton lifestyle and the
latter a transient one. What do you think?

> 
> > > Look at the code in the Cocoon bean. The Target class does offer 
> > > different ways to help with the decision as to how the 
> destinations 
> > > are generated. It can cater for single files being 
> generated, or for 
> > > whole sites being spidered (even from one target).
> > > 
> > > There's much that could be done on the bean iteself to extend its 
> > > functionality - and this would make it more useful to Bean and to 
> > > CLI users alike.
> 
> Have you looked at the Target class? Does it seem helpful? 
> I've added info to the wiki 
> (wiki.cocoondev.org/Wiki.jsp?page=CommandLine), see section 
> 7, that explains them a bit more.

Ah that is a very helpful page. The Target class definitely seems to
cover my use case.

Unico

Mime
View raw message