cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [RT] Better Environment Abstraction
Date Tue, 31 Dec 2002 13:53:58 GMT

I have some problems I need to solve:

1) I want to use Cocoon as a bean in other programs, as an evolved xml 
processing bean. I want to create it, set input (stream), set output, 
and execute.

Problem: I cannot do it with the current Cocoon, without creating my 
specialized environment to put the input and a Generator that gets from 
that and generates.

2) I want to execute transformations of mails in a James mailet using 

Problem: I have a similar problem to (1).
Cocoon doesn't get input directly from the request, unless from a webapp 
HttpServletRequest, which is not really feasable here.

3) The StreamGenerator depends on the servlet package, so Cocoon cannot 
compile without it. So much for blocks and reduced dependencies on core. 
Cocoon should be able to run in a smaller space, without depending on 

Problem: As we use Cocoon in a container != to a servlet container 
(Avalon Phoenix, Mod-Cocoon) we loose the StreamGenerator functionality, 
or portaility of the sitemap, unnecessarily.

So I cannot get a stream from the Request in a standard way, though it's 
IMHO a reasonably common operation, that should thus be abstracted.

With Vadim we have discussed about it a bit and we found that:

1) not all env. have the need (CLI), but most do
2) some env.s (mail) have multiple inputs
3) IMHO all env.s have a main input (mail content)
4) it's possible to get these from the Request as attributes instead of 
as a stream. This makes it more flexible because I can pass objects, and 
more than one. Standard entries can be added.
5) getting stuff from a Request attribute means that I need to parse all 
the request. This increases memory usage, but sometimes is inevitable, 
because of the protocol used (mail attachments)
6) getting from a stream can make it easy to make it more efficient on 
input->output transformations, typical of web services.

So, from these, I seem to think that we could

1) add a getInputStream() to the Request
2) make other input features available through request attributes

In case of mail

1) the mail content goes through getInputStream()
2) the attachements go through Request attributes

There are other possibilities, this is what ATM seems more common ground 
and pragmatic.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message