Hi, My goal was to speed up indexing avoiding to request XML documents via http: URL. Thus I wrote org.apache.cocoon.components.crawler.LinkSamplingEnvironmentCocoonCrawlerImpl.
As I thought about how to configure, and invoke it I came up with the Action design pattern. The idea is to wrap some action which you want Cocoon to do into an Action abstraction. This way you can trigger Cocoon to do some actions via commandline. I designed following CocoonActions: * CocoonActionGenerateIndex * CocoonActionGeneratePage * CocoonActionGenerateXSP * CocoonActionGenerateSitemap * CocoonActionCrawler * ForEachCocoonAction. Now from the commandline you can control which actions should get invoked, and in which sequence the actions get invoked. I have defined following commandine options: --followLinks : create a CocoonActionCrawler --generateIndex : create a CocoonActionGenerateIndex --generatePage : create a CocoonActionGeneratePage --generateXSP : create CocoonActionGenerateXSP --generateSitemap : create CocoonActionGenerateSitemap Note: * CocoonActionCrawler has an internal CocoonAction set, which is triggered for each crawled URI * CocoonActionGenerateIndex invokes an CocoonCrawler by definition About ant I first thought about writing an ant task for my purpose, but I think a dummy ant wrapper will work, just forking the Cocoon main class, and the commandline options become ant datatypes or subtasks. Then you can have somethink like that, in the future: <cocoon destDir="/foo/bar" contextDir="/cooon/documentation"> <generatePage followLinks="true"/> <generateIndex indexDir="index"/> </cocoon> > > > Some time ago I wrote a very quick and really dirty Cocoon Ant task, > and I had to go the copy and paste approach which is really bad: this > is just one of the examples of another possible Cocoon usage. me, too. > > > But there are plenty of possible environments that might leverage > Cocoon as an "XML Enabler" technology, if only it was easier to write > Cocoon enabled applications. So, while I cannot guarantee lots of time > as of now, I'd like to see if there is interest in this task from the > team and, if so, start thinking about (I know that Stefano will kill > me for this :)) a small set of APIs that might be embedded in > different contexts (be it Servlet, Command Line, Ant tasks, EJBs and, > why not, standalone applications). About EJB: I thought about that too, but the EJB environment is pretty restrictive. I think you are not allowed to create new threads, you are not allowed to write to disk, etc. Perhaps you can configure the cocoon.xconf to avoid Avalon to start any new threads. In EJB probably you need to wrap Cocoon into a stateless EJB. Servicing request; you may have to add another environment beside the currently available environment.commandline, and environment.http. Perhaps you may copy&paste the commandline environment stuff. Then you might have an EJB doing what, acting like a Cocoon servlet? bye bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
