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