Unico, > Hi, sorry for replying so late, I have been experiencing mail problems > and had to dig this one up from the archives.
No worries - this is unfortunately a part time persuit for me too. > > 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> Okay. But why do you want to create a Cocoon object as independent from the Cocoon bean? Why can't the bean create and configure it for you? > <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'm afraid I don't quite understand. Can you explain more? I don't quite understand what you mean by these two scenarios. You want the bean to create and configure cocoon (which I presume it already does). By the latter, are you referring to stuff like following links? > > > > 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. Why do you want to share the same Cocoon instance? Is it a performance thing? > 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. So are you saying that you create a CocoonBean around the Cocoon instance created by the HTTP Servlet and hand that bean over to other systems for them to use in rendering URIs? > 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> That is the primary purpose of the bean. > <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> Okay. > <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 ;) No, not at all, I appreciate the interest! > 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. This is exactly what I have in mind for the bean/cli. I made the bean write to ModifiableSources so that it can write directly to such things as remove FTP servers. So I would create a PublishingGenerator or PublishingTransformer that takes in a configuration (like the current cli.xconf) which tells the publisher what to do. That then gets hold of a Bean and hands the info to the bean for processing. The bean is then responsible for generating the pages and dispatching them to their final location (by simply opening an output stream on a modifiable source). The Bean could then write to a specified listener every time a file write is completed, which is then passed on to the next stage of the pipeline. So if you get it so that the Cocoon HTTP servlet can call the bean, you get delivery to multiple destinations via multiple protocols pretty much for free. If you need to create modifiableSources for your protocols, you can then also give those sources to the whole Avalon and Cocoon communities. > 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 would stick for the moment with the xconf format that the bean (well, actually the CLI) uses. It would be possible to make the bean configure itself from an xconf file passed in as SAX events, or as a Configuration object, which would enable it to be configured in a number of ways. But if the publicationService is just running as a Cocoon sitemap component, then I'd suggest it gets its configuration from its incoming SAX stream (probably identified with an appropriate namespace). Then the site builder can decide exactly where the info comes from, and adapt it as required, even at runtime. > 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. To my mind, the browser response in such a situation is a report saying whether or not the generation of pages was successful. I would say there's two sides to the approach I would recommend: small steps, and keep it compatible where possible. Let's identify small ways we can get the functionality we want, whilst respecting the interfaces that others are quite possibly using. So, what first small steps would assist you in your work? Regards, Upayavira
