-
1. Re: Connection to Apache Cocoon
no - this is currently not possible.
i don't know if any thought has been given to a future module, but if it's functionality you need, feel free to hack away and contribute to getting it done. -
2. Re: Connection to Apache Cocoon
There is much functionality in Cocoon that would be great to have in Nukes. I'm personally interested in seeing this happen.
Having said that, there are substantial challenges along the way, especially if we want to do a decent job. Some of the architectural decisions include...
Rewriting Cocoon functionality from scratch would take quite a while, plus the time to get it debugged and solid to the level that Cocoon already is today. And Cocoon has a nice clean architecture for some things, such as specifying pipelines of XSLT transformation stages. IMHO, it will turn out to be wise to reuse at least substantial parts of Cocoon.
OTH, Cocoon sits on top of the Avalon framework. JBoss makes Avalon redundant; JBoss long ago accomplished more than Avalon has sought to accomplish over its 4 major incarnations.
Some of the candidate ways to bring Cocoon to JBoss/Nukes include:
1) Avalon adapter --- simulate Avalon API, but use JBoss infrastructure to implement it.
2) Embed Avalon Fortress --Fortress contains a framework to help you create your own avalon containers. It boasts asynchronous management of your component instances, high scalability, easier maintenance of your code, and easy embedding into various environments like servlet engines.
3) Rewrite the low levels of Cocoon, to directly sit on JBoss, or more likely, on top of a Nukes module.
4) Completely decompose Cocoon, deeply integrate its "Reactor" pattern with JBoss/Nukes "Interceptor" pattern and other facilities, and sort the Cocoon code into multiple composable Nukes modules. Special attention would then have to be paid to putting it all back together properly, so that existing Cocoon sitemaps would continue to function, and other work that has been done on top of Cocoon could be easily brought over. This might be the hardest option, and maybe shouldnt even be attempted until something like 1, 2, or 3 above is solid.... but it would yield the deepest synthesis, and would provide all sorts of wonderful functionality.
Clearly, this is ambitious stuff that we'd be lucky to get for a Nukes 2.0 release. We need to start much smaller with XML/XSL processing for Nukes.
As a much simpler step in the XML/XSL direction, I'm hoping to first contribute some work on a simple facility to load the Nukes entities from XML (rather than DDL, and do it thru proper invocations on the Entity EJBs rather than going directly via SQL to the DBs), and also go the other direction (dump the DB to XML). I'm hoping to learn enough how to contribute to the Nukes effort that I can get something like that into a 1.1 release.
But the focus now has to be on getting a good solid 1.0 shipped... so let's turn our attention as loyal Nukes users towards helping the core team concentrate on the essentials. Let's pick this Cocoon thread up again a few weeks after the 1.0 is out the door?