> > 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?
If I can make it that all parts of the system can share the same Cocoon object then I would definitely prefer that. Because apart from memory, there's also the cache that is shared. > > > > > 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. I don't think it is necessary to make it thread-safe though. Once we factor out the Cocoon creation code CocoonBean would become a lightweight object. > > > 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. Perhaps CocoonServlet could put it in the application Context object. > > > > 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). Sounds good to me. > > > > 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. OK. I'll also have to rearrange initialize() for that because some stuff still needs to be executed either way (run related stuff) and some stuff shouldn't (Cocoon creation stuff). > > > 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? I don't agree that sitemap components are the way to go. Of course a set of sitemap components requires minimal or no changes to Cocoon core components and provides a lot of familiar plumbing. But the fact is that it's an awkward arrangement of responsibilities: Cocoon manages and runs sitemap components that in turn (manage and) run Cocoon. I think that the role of the sitemap and its components should be more or less constrained to creating documents. > > > 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. Exactly. > > (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). Great! We could eventually also supply a way to delete remote resources when they no longer exist locally. > Keep this coming, I'm enjoying this... I ain't going anywhere :) Unico
