You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ricardo Rocha <ri...@apache.org> on 2000/06/22 21:31:30 UTC
Re: javax.servlet.context.tempdir todo
Cool! Thanks a lot, Willie
Willie Wheeler wrote:
>
> Hi all,
>
> I'm brand new to open source development, so I hope I'm submitting this
> proposed change correctly. (Someone please tell me if I'm not.) Anyway,
> one of the Cocoon2 todo's is to make Cocoon use the
> javax.servlet.context.tempdir instead of having to use the cocoon.xconf
> file. I've modified the CocoonServlet.java and ProgramGeneratorImpl.java
> files.
> Here are the diff files:
>
> CocoonServlet diff
> ------------------
> 60a61,63
> > String tempDir =
> >
> ((java.io.File)this.context.getAttribute("javax.servlet.context.tempdir")).g
> etPath();
> > System.setProperty("org.apache.cocoon.defaulttempdir", tempDir);
>
> ProgramGeneratorImpl diff
> -------------------------
> 98,99c98,99
> <
> < this.repositoryName = params.getParameter("repository",
> "./repository");
> ---
> > String tempDir =
> System.getProperty("org.apache.cocoon.defaulttempdir");
> > this.repositoryName = params.getParameter("repository", tempDir);
>
> This allows you to use the cocoon.xconf to specify the temporary repository
> if you like. If you don't specify the repository parameter in cocoon.xconf,
> the default repository for saves is the value of
> javax.servlet.context.tempdir.
>
> Bye for now,
> Willie
Re: Pulling the HTML out of CocoonServlet
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sat, Jun 24, 2000 at 04:39:31PM -0400, Willie Wheeler wrote:
> Hi Giacomo,
>
> Hehehe, yeah, I got Stefano's message just after I sent mine out.
> Forget about my patches I think--I think it best just to start afresh, in
> light of what SM said.
Ok :)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Pulling the HTML out of CocoonServlet
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi Giacomo,
Hehehe, yeah, I got Stefano's message just after I sent mine out.
Forget about my patches I think--I think it best just to start afresh, in
light of what SM said.
Talk to you soon,
Willie
On Sat, 24 Jun 2000, Giacomo Pati wrote:
> On Sat, Jun 24, 2000 at 09:34:55AM -0400, Willie Wheeler wrote:
> > Hi Giacomo,
> >
> > I'm not sure what the best way is to send code, but I guess I will just
> > attach it. Here is my first pass at pulling the HTML out of CocoonServlet.
> > I created a Reporter interface (for reporting not only exceptions, but
> > simple messages as well). I also wrote a HtmlReporter class, which formats
> > exceptions and messages in HTML. Let me know if this is going in the right
> > direction.
>
> Hi Willie
>
> Did you get the proposal from Stefano? He is that smart telling what his visions concerning a general error handling would be.
>
> Can you produce diffs for the patches.
>
> Giacomo
>
>
Re: Pulling the HTML out of CocoonServlet
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sat, Jun 24, 2000 at 09:34:55AM -0400, Willie Wheeler wrote:
> Hi Giacomo,
>
> I'm not sure what the best way is to send code, but I guess I will just
> attach it. Here is my first pass at pulling the HTML out of CocoonServlet.
> I created a Reporter interface (for reporting not only exceptions, but
> simple messages as well). I also wrote a HtmlReporter class, which formats
> exceptions and messages in HTML. Let me know if this is going in the right
> direction.
Hi Willie
Did you get the proposal from Stefano? He is that smart telling what his visions concerning a general error handling would be.
Can you produce diffs for the patches.
Giacomo
RE: Pulling the HTML out of CocoonServlet
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi Giacomo,
I'm not sure what the best way is to send code, but I guess I will just
attach it. Here is my first pass at pulling the HTML out of CocoonServlet.
I created a Reporter interface (for reporting not only exceptions, but
simple messages as well). I also wrote a HtmlReporter class, which formats
exceptions and messages in HTML. Let me know if this is going in the right
direction.
Willie
-----Original Message-----
From: Giacomo Pati [mailto:Giacomo.Pati@pwr.ch]
Sent: Saturday, June 24, 2000 1:42 AM
To: cocoon-dev@xml.apache.org
Subject: Re: Pulling the HTML out of CocoonServlet
Hi Willie
On Fri, Jun 23, 2000 at 09:32:56PM -0400, Willie Wheeler wrote:
> Hi Giacomo,
>
> Can you explain the idea of contexts here in more detail? Are the
contexts
> just the different targets to which the XML could be transformed? (I am
not
> familiar with SOAP, sorry.)
Cocoon will be used in different contexts. Mostly in the HTTP environment
but also as mail creator, or atthe commandline to generate some documents.
> What would the API for the abstract
> context-neutral class look like? If I understand you correctly,
> CocoonServlet would delegate to an ErrorReporter, which contains the
> hardcoded HTML (or whatever other formats we output to).
The idea is not very concrete. I first thought of an simple CocoonException
every Exception that should arrive the calling environment is based upon
(something that we as developer must make sure). Based on the environment,
cocoons can be configured to use a subclass there of for rendering the error
message (as an web page, as a mail, ...)
> Is it important
> for end users to be able to modify/customize the error messages that
Cocoon
> displays? If so it might be better to use a server page and XSLT, as
> opposed to a Java class.
Not, realy. It is good to use an interface/abstract class in the core cocoon
and have a subclass be defined for a specific environment. If someone
doesn't like it, he can change almost the java class.
> Let me know what you think. And if you already have some concrete plans
on
> how to proceed, tell me what they are so I can get started! :-)
No concrete plans, just thoughts.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Pulling the HTML out of CocoonServlet
Posted by Giacomo Pati <Gi...@pwr.ch>.
Hi Willie
On Fri, Jun 23, 2000 at 09:32:56PM -0400, Willie Wheeler wrote:
> Hi Giacomo,
>
> Can you explain the idea of contexts here in more detail? Are the contexts
> just the different targets to which the XML could be transformed? (I am not
> familiar with SOAP, sorry.)
Cocoon will be used in different contexts. Mostly in the HTTP environment but also as mail creator, or atthe commandline to generate some documents.
> What would the API for the abstract
> context-neutral class look like? If I understand you correctly,
> CocoonServlet would delegate to an ErrorReporter, which contains the
> hardcoded HTML (or whatever other formats we output to).
The idea is not very concrete. I first thought of an simple CocoonException every Exception that should arrive the calling environment is based upon (something that we as developer must make sure). Based on the environment, cocoons can be configured to use a subclass there of for rendering the error message (as an web page, as a mail, ...)
> Is it important
> for end users to be able to modify/customize the error messages that Cocoon
> displays? If so it might be better to use a server page and XSLT, as
> opposed to a Java class.
Not, realy. It is good to use an interface/abstract class in the core cocoon and have a subclass be defined for a specific environment. If someone doesn't like it, he can change almost the java class.
> Let me know what you think. And if you already have some concrete plans on
> how to proceed, tell me what they are so I can get started! :-)
No concrete plans, just thoughts.
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
[RT] parallel pipeline streams
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Willie Wheeler wrote:
> >
> > Hi all,
> >
> > Also, I'd like to tackle the todo that says to pull the HTML out
> > of CocoonServlet, if somebody isn't already working on it. I'm thinking
> > that it would be good to forward to a dynamically generated error page.
> > Is this what people have in mind?
>
> Thank's for your offer to help.
>
> I had the vision of something like an abstract, context neutral class
> that handles the error cases. Implementing concrete classes base upon it
> for the different contexts (mail, soap, html, ...) Cocoon might be
> working in. Maybe pluggable ErrorReporters?
Hmmmm, yeah, something like that.
I have the usual burst of RT about this. Here they come...
I picture four error levels divided into two stages
1) adaptor |
2) engine |---> startup
3) component |
4) pipeline |---> operation
if the adaptor (servlet, command line) signal an error, it cannot use
any of the engine functionalities. In this case, it should use its own
error channel, for example
servlet -> servlet log
mailet -> mailet log
command line -> STDERR
avalon block -> avalon logger
(note: there is no SOAP adaptor, SOAP is a protocol not a component
model, SOAP operation will be performed inside avalon, together with RMI
or CORBA these are different flavors of the same thing but we should not
care about "how" the cocoon execution is triggered but only "who" does)
Adaptor errors might be:
- class not found
- properties not found
- container is not powerful enough
- java version is too low
- your memory is not enough
- etc...
Now, when the adaptor sees that everything is good, it launches the
engine (org.apache.cocoon.Cocoon for C2). At this point, the engine
might generate errors:
- configurations not found
- sitemap not found
- can't read directory
- can't find class
- xml not-well formed
- etc...
I believe these should be sent back to the adaptor without any markup
formatting, the adaptor will know what to do with them.
The component layer will throw exception the engine will caught and
signal the adaptor.
NOTE: the adaptor could implement the ErrorHandler interface and it
could pass itself as an ErrorHandler interface to the engine.
So far for startup.
Now our engine is running and we are all well.
At runtime there are two modes of operation:
1) operation data
2) operation metadata
in 1) is where Cocoon works as expected
in 2) is where Cocoon generates data about the data previously generated
or contained inside
Case 2) is the infamous /Cocoon.xml page for C1, but also contains the
debug information you receive when something is wrong in your page, for
example, when the page is not well-formed or when the stylesheet cannot
be found.
Many people would like to incorporate this information nicely inside
their web site, removing Cocoon-specific graphics and having the chance
to filter out sensible information depending on who access the faulty
page.
More over, Cocoon should keep track of its own timings and provide this
information in a consumable form.
Again, I see two cases:
a) runtime metadata
b) runtime errors
For runtime metadata, there are no big problems. I picture
org.apache.cocoon.Cocoon implement Generator as well so that it can be
used to generate metadata about itself using whatever schema we decide
it's more convenient. Then it's up to you to place this into your
sitemap and manipulate it as you like... maybe creating png pictures of
the usage statistics, thru XSLT filtering and SVG serialization. Anyway
the above doesn't require any change in our model, it might also be
implemented as XSP or directly in code, this is up to who implements it.
For runtime errors, the situation is much more complex.
Runtime errors should be sent to the requestor, not to the underneath
error log. This is to avoid the hassle of having to open the log file
everytime something is wrong and understand which one was your log
(consider an environment where thousands of people are working on the
same cocoon at the same time!).
During pipeline operation there are two layers
------- data -------->
----- metadata ------>
data is what the client normally sees, we can call it "the surface
stream", metadata is what is generated "sideways" by the pipeline (for
example timing contents, pipeline tracing instructions, xslt messages,
etc), we can call it "the underground stream".
Cocoon1 merges the two pipelines using comments: the infamous "<!-- this
page was generated by Cocoon.... -->" comment is the only metadata
generated, but I believe it's pretty important both for recognition (to
tell if the page was generated by cocoon) and performance tuning (as
well for cache operation).
How do we integrate the two pipelines?
For electronic signal handling, two channels can be merged using
orthogonal ways of propagation. But they are lucky (well, from this
point of view anyway), since they know they are using electromagnetic
waves only.
Here we are using _any_ possible binary format and there is only one
channel in an ordered octet stream. So, how do we do this?
First solution: discriminate for format
1) use the orthogonal channels were possible (comments, or XML
namespaces)
2) don't use them were this is not possible (general text, images, pdf,
etc...)
Second solution: discriminate for request
1) if the normal URI is called serialize the surface stream
2) if a special URI is called use the underground stream as a generator
for another pipeline.
This might require sitemap changes to incorporate the idea of parallel
streams.... well, food for thought.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
RE: Pulling the HTML out of CocoonServlet
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi Giacomo,
Can you explain the idea of contexts here in more detail? Are the contexts
just the different targets to which the XML could be transformed? (I am not
familiar with SOAP, sorry.) What would the API for the abstract
context-neutral class look like? If I understand you correctly,
CocoonServlet would delegate to an ErrorReporter, which contains the
hardcoded HTML (or whatever other formats we output to). Is it important
for end users to be able to modify/customize the error messages that Cocoon
displays? If so it might be better to use a server page and XSLT, as
opposed to a Java class.
Let me know what you think. And if you already have some concrete plans on
how to proceed, tell me what they are so I can get started! :-)
Willie
-----Original Message-----
From: giacomo@xml.apache.org [mailto:giacomo@xml.apache.org]On Behalf Of
Giacomo Pati
Sent: Friday, June 23, 2000 5:24 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Pulling the HTML out of CocoonServlet
Willie Wheeler wrote:
>
> Hi all,
>
> Also, I'd like to tackle the todo that says to pull the HTML out
> of CocoonServlet, if somebody isn't already working on it. I'm thinking
> that it would be good to forward to a dynamically generated error page.
> Is this what people have in mind?
Thank's for your offer to help.
I had the vision of something like an abstract, context neutral class
that handles the error cases. Implementing concrete classes base upon it
for the different contexts (mail, soap, html, ...) Cocoon might be
working in. Maybe pluggable ErrorReporters?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Re: Pulling the HTML out of CocoonServlet
Posted by Giacomo Pati <Gi...@pwr.ch>.
Willie Wheeler wrote:
>
> Hi all,
>
> Also, I'd like to tackle the todo that says to pull the HTML out
> of CocoonServlet, if somebody isn't already working on it. I'm thinking
> that it would be good to forward to a dynamically generated error page.
> Is this what people have in mind?
Thank's for your offer to help.
I had the vision of something like an abstract, context neutral class
that handles the error cases. Implementing concrete classes base upon it
for the different contexts (mail, soap, html, ...) Cocoon might be
working in. Maybe pluggable ErrorReporters?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen Web: http://www.pwr.ch
Pulling the HTML out of CocoonServlet
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi all,
Also, I'd like to tackle the todo that says to pull the HTML out
of CocoonServlet, if somebody isn't already working on it. I'm thinking
that it would be good to forward to a dynamically generated error page.
Is this what people have in mind?
Willie