Maybe I am missing something fundamental, but I don't see how using Cocoon as a service violates IoC? Cocoon naturally provides the Processor interface as a service. The current CocoonServlet initializes the Cocoon component and then delegates HTTP requests to the Cocoon Processor. My goal is to move the initialization step to a block. Then I would write a Servlet that looks up the Processor and delegates the HTTP request ala CocoonServlet. Why do this? Well, now I can deploy multiple wars in my Servlet container all using a shared Cocoon component. I could even use Cocoon from a MessageDriven EJB. This is the idea anyways. Hopefully it works in practice.
I believe the advice given to you by cocoon-dev was to not call sub-components of Cocoon (i.e. components defined in cocoon.xconf and the sitemap.) Of course you have to call into the Cocoon Processor, otherwise, how would you use it! Requests have to get passed into Cocoon somehow :) I would be glad to donate the Cocoon block and servlet back to this project. I'm sure it won't be perfect, and having a community of developers review it can only make it better. I expect to have something workable in the next few days. Regards, --mike -----Original Message----- From: Uli Mayring [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2001 7:32 AM To: Avalon Developers List Subject: Re: Integrating Cocoon (was: Access to Application ClassLoader from a Block?) On Sun, 25 Nov 2001, Paul Hammant wrote: > Not answering your question (Pete has), but when you've finished can you > publish the code back to us? We plan, sooner or later, to make a block > that publishes Cocoon services internally and this sounds very > close......... I was planning something like that for a long time, too. When I asked on cocoon-dev about the way to go the relevant people said that I should take care to not violate IoC and to not deconstruct Cocoon in a way that would make it unrecognizable as a project of its own. The majority of people, who spoke out on this issue, thought that I should not call a Cocoon component from my other components, but that I should have Cocoon call my other components. This is to preserve IoC, a "Cocoon block" would violate it, as it can be called from outside. That would mean that I should not bypass, for example, the Sitemap to access "inner services" directly. There should be only one entry-point into a Cocoon component and it should, if possible, be the same one as in a standard download of Cocoon. If we accept this as a given, then the follow-up argument "have Cocoon call your other components" sounds inevitable to me. When I say "Cocoon" in this context I do not mean the current Cocoon, but the Cocoon that will remain after the on-going integration of several of its components into Avalon. When that work is done, the whole issue might present itself very differently. The original poster apparently thinks of integrating the current Cocoon into Avalon - something which may have no future in the light of the on-going migration of components from Cocoon to Avalon. I have meanwhile started along a different path. The whole IoC argument as I tried to represent it above, didn't fit well with our currently existing applications, which are all running under Phoenix. So I've written "my own stripped-down version of Cocoon", something I called an "XML-Block". It currently does XSL(T|FO) and can render to all the output formats fop supports (it uses fop, xerces and xalan internally). This is of course just a small part of what Cocoon does, but for me it's better to start small and work my way up, instead of the other way round. That means I'm not using any of Cocoon's code, I think it would be too difficult to keep it synched with the Cocoon project, unless there was a broad agreement on philosophy, IoC or otherwise. The beauty of OpenSource is that I can do my own thing and nobody has to agree with me and I have to agree with nobody :-) cheers, Ulrich -- Ulrich Mayring DENIC eG, Softwareentwicklung -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
