Unico, > > 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? > 1) because CocoonBean is single threaded and I need to run concurrent > requests.
Fair enough. > 2) because I want to share the same Cocoon instance for > performance. Fair enough. > > > <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? > > Yes. The code in CocoonBean can be seperated into two categories. One > is for creating and configuring the Cocoon instance it is going to > use, the other is using it. Cocoon is thread-safe. CocoonBean is not. Sounds reasonable. The code in the bean is not that well organised. It is written in Java, but it is pretty procedural. It could do with being broken down into clearer parts. That is probably the most obvious first split. > > 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? > > No I have an Avalon component that creates and manages Cocoon. The > http servlet and publishing service get it from a ServiceManager they > receive. I don't use CocoonBean now. Sorry, I meant 'is that how you would do it' rather than 'is that how you do it now'. So you would create another cocoon instance and have the bean handle and share that, rather than sharing the servlet's cocoon instance? > > > 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. > > Except that it's not useable in a multi-threaded environment unless > you create one CocoonBean per thread. Yes. But the bean is at a very early stage of its development. That is what it is intended for, but not necessarily what it is ready for. Your proposals and help could make it so. > > 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. > > The first generation of my publisher was actually triggered by a > Cocoon Action. Sitemap parameters controlled the way the publisher was > run. We experienced problems with it because it ate memory thus > crashing our system when publication requests came in concurrently. > Apart from that configuration was becoming a drag for our sitemap > editors and clogged up the sitemaps with unreadable action logic. I think the best place for the configuration is as an input to a sitemap component, either as incoming SAX events, or as a src attribute: <map:generate type="publish" src="publish.xconf"/> > The problem with running the publisher from sitemap components is that > there is no access to Cocoon object from there (would be rather > awkward design too). So requests can't be run locally. Ah. So how about we find a way for CocoonBean instances to share an instance of Cocoon? We can have an additional Cocon instance alongside that of the HTTPservlet. Otherwise we work out a way to get hold of the Cocoon instance of the servlet. > > 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. > > :) As it happens I commited a patch for an FTPSource to Avalon a few > days ago that was applied yesterday. Wow. What a treat! Looks great. That is going to make my life so much easier in the future. > > To my mind, the browser response in such a situation is a > > report saying whether or not the generation of pages was successful. > > That's an option. However, some publications can take a long time when > it also involves crawling and the sites are large and/or slow. Also, > publication processing like this is very resource intensive. For this > reason we had to process the requests asynchronously, queueing them if > a lot of concurrent requests come in. Okay. So the bean needs to log to a particular logging category what it is up to, so that you can tell whether it succeeds or not, and then return to the next sitemap component (as SAX events) either the results of the page generation (if done synchronously) or the fact that a request was successfully made to the bean (if done asynchronously). > > 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? > > Well, I'd like to use CocoonBean for publication runs, but I want to > reuse Cocoon instance. So as a start I think adding a constructor to > CocoonBean like you proposed would be a good start. Great. Send me a patch and I'll commit it. > After that there are several possibilities: > > 1) Separate publisher service: > > - In order to create a CocoonServlet subclass that gets its Cocoon > from elsewhere instead of creating it itself: change access modifier > of CocoonServlet.getCocoon() method from private to protected. > > - CocoonService that wraps Cocoon to embed it in an Avalon container > (I already have part of that code) and/or JNDI resource factory that > makes Cocoon object available to webapp from JNDI (does not require to > run Avalon enabled web environment). I am very keen on a sitemap component. If the bean needs to create its own shared cocoon, then that'll be only two cocoon instances instead of one. Can you explain more about how you would do this? How would you organise the asynchronous generation and triggering of that? > Judging from fact that most cocooners aren't exactly milling around in > exitement about this publisher service I think keeping it as a > separate component would be preferred. I think you shouldn't underestimate the importance of this publisher service. People might not be stating their needs of it, but if we do a good job of designing it, it stands the chance to become a key part of Cocoon. I've got a Cocoon based site that is basically static, but makes use of Cocoon caching. But even that is overkill. Why not just upload the site to the server and run the publish service? Or run the publish service locally and have the publish service upload it for you. To an FTP server, to a CVS server, to a... Then all you need is Cocoon, or Apache, to serve static content. (I've got some code (that doesn't yet work) that'll make the bean only generate pages that haven't changed. That'd make the publishing service even more powerful if we can get it working). Keep this coming, I'm enjoying this... Regards, Upayavira
