Hi, sorry for replying so late, I have been experiencing mail problems and had to dig this one up from the archives.
> I think the alternative constructor would do it definitely. Although I > would miss all the functionality that CocoonBean provides for creating > and initializing Cocoon. <uv> So what functionality are you referring to here? Surely you don't want to go configuring the Cocoon instance if it has already been configured elsewhere (by its containing servlet). </uv> <uh> No, but I could use it wherever I do create and configure it. Be that in a servlet or in an Avalon embedded component. Although it wouldn't be a problem to do that without the help of a utility class and I am doing exactly that right now, my suggestion was that it might be useful. </uh> <uv> Are you suggesting that we might want the bean to be able to generate a page from a webapp that isn't being served by the servlet? </uv> <uh> I'm saying that I see two separate areas of concern that CocoonBean could be useful for me. One is to help create and configure Cocoon, the other is to help run Cocoon and gather information about these runs. The former would be useful for me in a thread safe type component where I create and manage a shared cocoon instance, the latter I'd like to use in the per-thread situation of a publication request. </uh> > > > 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? <uv> So, what do you mean by 'shared between clients'? </uv> <uh> I mean that the same Cocoon instance be accessible from different locations in the system. One client of this "Cocoon service" would the HttpServlet that handles regular http calls. Another a mail system that publishes pages over smtp, and yet another that receives commands to push pages onto a remote server as part of a publication action. Actually that was what I started out from, because the publication system I have now follows this exact approach. It accesses the same Cocoon instance that is used to handle http requests as well. Since it is separated from the http servlet I needed to put the Cocoon instance somewhere from where I could access it from both locations. But it isn't necessarily required for me to keep these two clients separated. It's just the way it works for me now, and divorcing Cocoon management from the code using it, is something that would be generally useful I think. </uh> <uv> Would you have the same bean running in multiple threads? </uv> <uh> No, the bean can be single threaded, but I would be running multiple CocoonBeans sharing the same Cocoon concurrently. </uh> <uv> Let's understand exactly what your requirements are, then we can look at how we might achieve it. </uv> OK, thanks for sticking with me so long, I hope I am not being too annoying ;) The basic requirement that I have is that of a webservice that pushes files onto a target location such as a remote FTP server. I consider two different approaches. One is to integrate the service with Cocoon as it now runs as a servlet or come up with an implementation that is separate from it. In the former case, publication requests might involve a protocol that is similar to Cocoon views. I am thinking that the sitemap could have a "targets" section that defines publication locations, the default being just the stream to the requesting client browser. Then, similar to the way views work, a cocoon request could be made by optionally specifying the target to publish to: http://cocoon/resource-to-publish?cocoon-target=myliveserver The other possibility is keeping the publication service separate from the CocoonServlet. Configuration would be outside the sitemap and I would need a way to share CocoonServlet's Cocoon and PublicationService's Cocoon. I think I prefer the first approach because it wouldn't require additional setup and configuration is right where you'd expect it to be. Seems cleaner somehow. It also circumvents the issue of sharing the Cocoon instances we were discussing before. On the other hand, http being a request-response type of affair, the browser response is not well defined. There's also the additional complexity added to the core of Cocoon. Rgrds, Unico
