Stefano et al,
I'm reading this thread with interest. If I may add a view as someone
who is most interested in Phoenix and the apps hosted on it.
Consider JAMES (the mail server) what if it wanted to render HTML
emails/news postings with XSP/XSL. There are ways that it could work
currently taking output from a dedicated web server and "paste" into
outgoing emails.
I see a typical Cocoon deployments as follows:
static pages Cocoon Instance as
other servlets WebApp incl all jars
| |
------------------
|
Site1/App1 Site2/App2
| |
-------------------------------------
|
WebServer
|
JVM1
What if this were the case:
static pages Cocoon Servlet as
other servlets small WebApp
| |
------------------
|
Site1/App1 Site2/App2
| |
-------------------------------------
| Cocoon Engine
WebServer JAMES Incl all jars
| | |
------------------------------------------------
|
Phoenix
|
JVM1
Or This:
static pages Cocoon Servlet as
other servlets small WebApp
| |
------------------
|
Site1/App1 Site2/App2
| |
-------------------------------------
| Cocoon Engine
WebServer JAMES Incl all jars
| | |
| --------------------------------
| |
| Phoenix
| |
JVM1 JVM2
What am I proposing?
Well firstly I think that it should remain posible to run Cocoon in a
Web-App, entriely contained and dropped as a war file into Resin,
Tomcat, Orion etc. My thinking is that that should be *one* deployment
possibility.
I am primarily proposing that we decouple the Cocoon concepts from the
servlet API. We make the usable outside a servlet context. We do
provide a number of ways of wrapping Cocoon as a servlet, but generalize
the real APIs
I see the separation of Cocoon into three/four core parts:
1) Cocoon Engine
This would inherit 95% of the functionality of the current Cocoon. It
would be "beanlike" though - able to be instantiated from a number of
contexts (see 3,4 below)
2) Servlet wrappers. Again inherited from the current Cocoon. A few of
these with a couple of variations:
2.1) A heavyweight servlet that adapts the Cocoon engine and is
equivaent to the current deployment style
2.1) A lightweight servlet that delagates via RMI or JNDI (you folks
heard of AltRMI yet) to the engine elsewhere
2.2) A lightweight servlet that delagates internally through the VM to
the engine (this breaks the "Servlet spec") as the context would be
passed up IoC style and most usable for situations where the webserver
and Cocoon are sitting on Phoenix.
3) A Phoenix wrapper for Cocoon engine. Failry small in it's own right,
but would expose pertinent interfaces internally to other phoenix blocks
(like JAMES).
4) A mainable launch mechanism for the Cocoon Engine. This needed?
We already have a phoenix compatible webserver called Jo! Maybe
sometime this year a few small tweaks are made to Catalina so we can
embed it in Phoenix.
Thoughts?
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
