RE: Divorse Cocoon creation from CocoonServlet
> > At the moment, the CocoonBean isn't an Avalon > > component (and I want to see it being possible to use it > > outside an Avalon context), but should be possible to make it > > into a component. Your maillet (for example) could then get a > > CocoonBean from Avalon and use it to write to the maillet's > > own output stream. > > > > Make sense? > > Yes that was about what I had in mind. I'll prepare a patch as soon as > I have something and commit it to bugzilla. Great. Upayavira
RE: Divorse Cocoon creation from CocoonServlet
Hi Upayavira, Thanks for your reply. > Unico, > > Have you looked at the CocoonBean. As I see it it is intended > to provide a simple interface for interacting with Cocoon. I've seen it and was intending to use it too! :) > It > is largely used by the CLI to batch generate pages > statically, but has a method to generate a URI and pass the > result to an output stream of your choosing (not sure if it > works, but wouldn't be hard to fix if it doesn't). > > In theory, the CocoonServlet could use the CocoonBean. This > would be a reasonable enough thing, were it not for the fact > that the CocoonServlet has benefitted already from a lot of > tuning and TLC. That's why as a start we could allow CocoonServlet subclasses to overide the way it gets to Cocoon. Right now I have my own CocoonServlet that has about 90% of original CocoonServlet copied. > At the moment, the CocoonBean isn't an Avalon > component (and I want to see it being possible to use it > outside an Avalon context), but should be possible to make it > into a component. Your maillet (for example) could then get a > CocoonBean from Avalon and use it to write to the maillet's > own output stream. > > Make sense? Yes that was about what I had in mind. I'll prepare a patch as soon as I have something and commit it to bugzilla. Regards, Unico
Re: Divorse Cocoon creation from CocoonServlet
Unico, Have you looked at the CocoonBean. As I see it it is intended to provide a simple interface for interacting with Cocoon. It is largely used by the CLI to batch generate pages statically, but has a method to generate a URI and pass the result to an output stream of your choosing (not sure if it works, but wouldn't be hard to fix if it doesn't). In theory, the CocoonServlet could use the CocoonBean. This would be a reasonable enough thing, were it not for the fact that the CocoonServlet has benefitted already from a lot of tuning and TLC. At the moment, the CocoonBean isn't an Avalon component (and I want to see it being possible to use it outside an Avalon context), but should be possible to make it into a component. Your maillet (for example) could then get a CocoonBean from Avalon and use it to write to the maillet's own output stream. Make sense? Regards, Upayavira On 18 Jun 2003 at 11:41, Unico Hommes wrote: > Hi all, > > I'd like to override getCocoon method in CocoonServlet in order to > allow another subsystem than the servlet create and manage Cocoon. > This so that the same Cocoon instance can be shared among different > clients adapting different protocols. More specifically I want to be > able to have Cocoon hosted as a component in some Avalon container, > have a servlet running inside the container provide access to it over > HTTP, and have other clients (eg. a mailet) provide access to it over > other protocols (eg. SMTP). > > But as it is now CocoonServlet.getCocoon() has private access, hence > this request to make it protected instead. > > My implementation would be a small wrapper around Cocoon so as to load > it in as a component in an Avalon container, and then make the servlet > Serviceable so as to be able to look it up from the provided > ServiceManager. If there is any interest in this I will provide a > patch. > > Regards, > Unico >
