You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Martin Man <Ma...@seznam.cz> on 2001/10/19 19:44:47 UTC
[RT] New validator and propagator infrastructure
hi all,
in response to well-known action flood we have seen over past
days(weeks) I'd like to propose rewrite of validator actions. The result
should be one "validator" action which will do the work of all existing
validator actions and maybe even more. I think we should do this before
2.0final, because it's not more than cleanup work... and I'm volunteering to
do it actually but first to hear some comments...
1. Validator
============
1.1. What to validate
---------------------
- request-attributes [java.lang.object]
- request-parameters [java.lang.string]
- session-attributes [java.lang.object]
- cookies [java.lang.string]
1.2. Supported types and validation criterias
---------------------------------------------
- long [min, max, equals]
- double [min, max, equals]
- string [max-len, matches-regexp, equals, equals-ignore-case]
- date [valid] (probably (min|max)-(day|month|year) ???)
- xml [well-formed, valid]
additionaly all datatypes will have attribute `nullable' and `default'
with obvious functionality.
1.3. Validation descriptor
--------------------------
will look as it is now with some additions,
<validate check="request, session, cookies">
<parameter name="xxx" type="section 2." optional criterias from 3.
check="cookies, session"/>
<constraint-set name="is-administrator" check="session">
<validate name="xxx" optional criterias from 3. check="cookies"/>
</constraint-set>
</validate>
note that attribute `check' will specify where to look for parameter,
request-attributes will be checked before request-parameters.
iner-most attributes take always precedence, so that easy overriding
mechanism is available
1.4. Invocation from sitemap
----------------------------
<map:act type="validator">
<parameter name="descriptor" value="...."/>
<!-- either whole set -->
<parameter name="validate-set" value="is-administrator"/>
<!-- or only enumerated parameters -->
<parameter name="validate" value="xxx, yyy, zzz"/>
</map:act>
1.5. Issues
-----------
- Should we try to validate parameter from next storage (according to `check'
attribute) if the first value fails or we should stop immediately...
- after given set (or parameters) are validated they're all available under
their respective names to sitemap via {name} expression. Here I think we
should try to extend the descriptor syntax and allow automatic propagation
of validated parameters into one of the following storages (see 2.1)
- because common use of validators is with database actions we *should* also
at least share the same descriptor for both types of actions, database
actions typicaly need only `name', `type' and table/collumn mapping... I can
see posibility to map given constraint-set to database table and <validate>
statements to provide mapping between parameters-columns (with additional
key/mode information).
- simple database authenticator can then also authenticate users against
given set because it will know which columns to fetch from which table and
to which parameters to compare them.
- how to extend descriptor syntax that would allow us to validate session
itself (as SessionIsValidAction and others)
2. Propagator (creator)
-----------------------
propagators were initialiy intended to ease the creation of various
parameters from sitemap, e.g.
<map:act type="propagator">
<parameter name="store-to" value="session"/> <!-- request, cookies -->
<parameter name="value" value="{1}"/>
</map:act>
2.1. Where to store (propagate)
-------------------------------
- to session attributes
- to request attributes
- to cookies
note that we can store arbitraty objects to session/request attributes and
strings to cookies. because brace expressions {name} are actualy objects taken
from map, we have to convert them to strings before storing into cookies, I
think we anyway use it for strings...
I'd like to see your comments and suggestions as well as existing experience
with validator/authenticator/propagator actions that we now have for almost 4
months. All those changes I'd like to do as soon as RequestContext will be
available (and I'm sure it will be ;-)
P.S. note that I left aside formval logischeet which surely will need the
appropriate changes as well, please attach comments/experience to this
topic as well (some new ideas Christian ???)
thanx for reading so far,
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] New validator and propagator infrastructure
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 19.Oct.2001 -- 07:44 PM, Martin Man wrote:
> hi all,
> in response to well-known action flood we have seen over past
> days(weeks) I'd like to propose rewrite of validator actions. The result
> should be one "validator" action which will do the work of all existing
> validator actions and maybe even more. I think we should do this before
> 2.0final, because it's not more than cleanup work... and I'm volunteering to
> do it actually but first to hear some comments...
Hi Martin,
I've been sitting here with some similar work regarding database
actions but haven't come around finishing them. The idea with them is
to put things that are DBMS dependant into components and specify them
as needed. Actually, after a while I started to put input and output
into components as well. Since it's still rather unpolished code and
not finished yet, I have not put it into CVS but you can find a copy
at http://www.dvs1.informatik.tu-darmstadt.de/~haul/misc/c2
There you'll find the following archives as well as the unpacked code
under extracted
modular_db.tar.gz the code
build.xml.diff.gz necessary to skip the informix
module when no informix jdbc driver
is present.
modular_db_example.tar.gz an example to mount at
cocoon/ch/mod-db. I had some
problems with relative context:
URLs here, so you might need to
change the sitemap.
The example uses a db connection
"test" which is currently an
informix db over here and I haven't
had the time to merge it into the
supplied db this morning.
test.sql.gz aforementioned db schema
Currently, ModularDatabaseAddAction uses code from AbstractSitemap to
load and configure the components but I think it would be better to
have them at least on sitemap level available.
The input / output work is delegated to three different kinds of
helper components:
-------- AccessHelper ----
| |
AttributeHelper KeyAttributeHelper
OutputHelper
AttributeHelper obtain values for non-key columns, e.g. from request
parameters or session attributes etc.
KeyAttributeHelpers obtain values for key columns. Since this involves
quite often autoincrements which are handled quite differently by each
DBMS it allows to get the value before or after the operation, even by
executing a query, and whether the value should be present in the sql
statement.
OutputHelpers store the query results somewhere, e.g. in request
attributes. They are also informed whether the transaction completed
successfully or was aborted.
The interface AttributeHelper is probably too complex. The idea was to
have a modified descriptor file that has three configuration options
for every column: a table configuration, a column configuration and a
mode configuration. Here the mode configurations contains the
important infos like the name of a request attribute.
I think this is not necessary and could be trimmed down to one
configuration and that way those helper components could be of use for
other actions, matchers and selectors as well.
I would be very glad to have some feed back on this. The next step
would be to add update, delete, and select actions as well. Then I
would have thought about making the helper components available to
other sitemap components. I might change that order now, though :-)
> 1. Validator
> ============
> 1.1. What to validate
> - request-attributes [java.lang.object]
> - request-parameters [java.lang.string]
> - session-attributes [java.lang.object]
> - cookies [java.lang.string]
There will always be some other place to look for the values as
well. E.g. we might want to obtain the values from some bean.
> 1.2. Supported types and validation criterias
> - long [min, max, equals]
> - double [min, max, equals]
> - string [max-len, matches-regexp, equals, equals-ignore-case]
> - date [valid] (probably (min|max)-(day|month|year) ???)
> - xml [well-formed, valid]
>
> additionaly all datatypes will have attribute `nullable' and `default'
> with obvious functionality.
+1
> 1.3. Validation descriptor
> will look as it is now with some additions,
>
> <validate check="request, session, cookies">
>
> <parameter name="xxx" type="section 2." optional criterias from 3.
> check="cookies, session"/>
>
> <constraint-set name="is-administrator" check="session">
> <validate name="xxx" optional criterias from 3. check="cookies"/>
> </constraint-set>
> </validate>
>
> note that attribute `check' will specify where to look for parameter,
> request-attributes will be checked before request-parameters.
>
> iner-most attributes take always precedence, so that easy overriding
> mechanism is available
I don't see why it would be necessary to have a sequence of places
where to obtain the values from, but I have no objections either.
> 1.5. Issues
> - Should we try to validate parameter from next storage (according to `check'
> attribute) if the first value fails or we should stop immediately...
Rather if it is not present. Failure -> stop, not present -> next storage
> - after given set (or parameters) are validated they're all available under
> their respective names to sitemap via {name} expression. Here I think we
> should try to extend the descriptor syntax and allow automatic propagation
> of validated parameters into one of the following storages (see 2.1)
I think it should be pluggable like the input.
> - because common use of validators is with database actions we *should* also
> at least share the same descriptor for both types of actions, database
> actions typicaly need only `name', `type' and table/collumn mapping... I can
> see posibility to map given constraint-set to database table and <validate>
> statements to provide mapping between parameters-columns (with additional
> key/mode information).
Indeed.
> - simple database authenticator can then also authenticate users against
> given set because it will know which columns to fetch from which table and
> to which parameters to compare them.
> - how to extend descriptor syntax that would allow us to validate session
> itself (as SessionIsValidAction and others)
Good point. One could write an input helper component that returns a
boolean value depending on this.
>
> 2. Propagator (creator)
> propagators were initialiy intended to ease the creation of various
> parameters from sitemap, e.g.
>
> <map:act type="propagator">
> <parameter name="store-to" value="session"/> <!-- request, cookies -->
> <parameter name="value" value="{1}"/>
> </map:act>
>
> 2.1. Where to store (propagate)
> - to session attributes
> - to request attributes
> - to cookies
>
> note that we can store arbitraty objects to session/request attributes and
> strings to cookies. because brace expressions {name} are actualy objects taken
> from map, we have to convert them to strings before storing into cookies, I
> think we anyway use it for strings...
>
>
> I'd like to see your comments and suggestions as well as existing experience
> with validator/authenticator/propagator actions that we now have for almost 4
> months. All those changes I'd like to do as soon as RequestContext will be
> available (and I'm sure it will be ;-)
>
> P.S. note that I left aside formval logischeet which surely will need the
> appropriate changes as well, please attach comments/experience to this
> topic as well (some new ideas Christian ???)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: R: [RT] New validator and propagator infrastructure
Posted by Martin Man <Ma...@seznam.cz>.
On Mon, Oct 22, 2001 at 08:45:42AM -0400, Vadim Gritsenko wrote:
> <snip useless stuff/>
>
> type="checkbox" is quite simple: absent parameter - false, present
> parameter - true.
> Value of parameter could be specified via (guess! :)) value attribute:
> <input type="checkbox" name="param" value="Yes!"/>
>
> So we could use null as false and not null as true.
yep, that's what I wanted to confirm, will add this functionality as well
>
> Regards,
> Vadim
>
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
R: [RT] New validator and propagator infrastructure
Posted by Paolo <la...@arsenio.net>.
Hi Christian!
> You are right: a checkbox value, as seen with Vadim, is a string with
a
> value of 'on', when selected. But a session or a request boolean
> attribute is an object, not a string. So we should process the source
> parameter differently depending by its source (request parameter or
> cookie are strings), and application/request/session attributes are
> objects.
>So, what if the part responsible for retrieving the object converts it
>to an object? We would only have to deal with objects for the
>validation then.
Yes. You are right. This is the best method!
Bye
Paolo Scaffardi
AIRVENT SAM S.p.A.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] New validator and propagator infrastructure
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 22.Oct.2001 -- 03:39 PM, Paolo wrote:
> You are right: a checkbox value, as seen with Vadim, is a string with a
> value of 'on', when selected. But a session or a request boolean
> attribute is an object, not a string. So we should process the source
> parameter differently depending by its source (request parameter or
> cookie are strings), and application/request/session attributes are
> objects.
So, what if the part responsible for retrieving the object converts it
to an object? We would only have to deal with objects for the
validation then.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
R: R: R: [RT] New validator and propagator infrastructure
Posted by Paolo <la...@arsenio.net>.
Martin!
>hmmm... this way we can catch some "no" "false" / "yes" "true"
You are right: a checkbox value, as seen with Vadim, is a string with a
value of 'on', when selected. But a session or a request boolean
attribute is an object, not a string. So we should process the source
parameter differently depending by its source (request parameter or
cookie are strings), and application/request/session attributes are
objects.
The request parameters can be checked by comparing the value with a
String like 'on', 'true', '1' and 'yes' (default parameter value can be
set to 'false' with 'nullable' flag for checkbox parameters). Other
sources with a boolean value.
I think it is important that the descriptor file should be
source-independent, and the source can be specified in the sitemap.
> Another thing: I forgot the application attributes in the list of
> sources of values to check from!
>here I don't understand what you mean by "application" attributes,
apart >from having possibility to check request and session someone
mentioned for >example beans, is this what you mean also ???
No, servlet specifications define many scopes for the attributes:
request, session and application. These are several places to store
attributes in a web application.
Bye,
Paolo Scaffardi
AIRVENT SAM S.p.A.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: R: R: [RT] New validator and propagator infrastructure
Posted by Martin Man <Ma...@seznam.cz>.
On Mon, Oct 22, 2001 at 03:15:54PM +0200, Paolo wrote:
> Hi Martin!
>
> > I'd like to add the boolean type, too.
>
> > yep, good point, but we have to agree what should be considered false
> amd
> > what true, .., if some web designer who knows how different browsers
> > behave for boolean types of input can provide me with the description
> I'll
> > be happy to add the functionality...
>
> I were talking about application/request/session attributes; the Boolean
> type is less usefull (I think) for request parameters. To implement that
> we can use the Boolean.valueOf() function to cast strings to booleans.
hmmm... this way we can catch some "no" "false" / "yes" "true"
>
> Another thing: I forgot the application attributes in the list of
> sources of values to check from!
here I don't understand what you mean by "application" attributes, apart from
having possibility to check request and session someone mentioned for example
beans, is this what you mean also ???
>
> Bye,
> Paolo Scaffardi
> AIRVENT SAM S.p.A.
>
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: R: [RT] New validator and propagator infrastructure
Posted by Vadim Gritsenko <va...@verizon.net>.
> -----Original Message-----
> From: Paolo [mailto:lavoro@arsenio.net]
> Sent: Monday, October 22, 2001 9:30 AM
> To: cocoon-dev@xml.apache.org
> Subject: R: R: [RT] New validator and propagator infrastructure
>
> Hi Vadim and Martin!
>
> >type="checkbox" is quite simple: absent parameter - false, present
> >parameter - true.
>
> >So we could use null as false and not null as true.
>
> This is not true! The default value passed as request parameter for a
> checkbox is the 'On' string!
Exactly - "on" is the _default_ value. It could be replaced with any
other string (you cut that part). And nothing is passed when checkbox is
not checked (i.e., null).
>
> And we want to use in the future the same descriptor file to validate
> not only request parameters, but session attributes or cookies, too...
>
> A flag is always stored in an application as a boolean, not as a
> null/not-null value. The best way, in my opinion, is to use a
'boolean'
> parameter type (that we will compare with 'On', 'Yes', '1' and
'True').
>
> For a checkbox, we can still use the 'nullable' flag with the
'default'
> value = 'false'.
>
> Am I right?
Yes, that's good suggestions.
Vadim
>
> Regards,
> Paolo Scaffardi
> AIRVENT SAM S.p.A.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
R: R: [RT] New validator and propagator infrastructure
Posted by Paolo <la...@arsenio.net>.
Hi Vadim and Martin!
>type="checkbox" is quite simple: absent parameter - false, present
>parameter - true.
>So we could use null as false and not null as true.
This is not true! The default value passed as request parameter for a
checkbox is the 'On' string!
And we want to use in the future the same descriptor file to validate
not only request parameters, but session attributes or cookies, too...
A flag is always stored in an application as a boolean, not as a
null/not-null value. The best way, in my opinion, is to use a 'boolean'
parameter type (that we will compare with 'On', 'Yes', '1' and 'True').
For a checkbox, we can still use the 'nullable' flag with the 'default'
value = 'false'.
Am I right?
Regards,
Paolo Scaffardi
AIRVENT SAM S.p.A.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: R: [RT] New validator and propagator infrastructure
Posted by Vadim Gritsenko <va...@verizon.net>.
> -----Original Message-----
> From: Martin Man [mailto:Martin.Man@seznam.cz]
> Sent: Monday, October 22, 2001 7:10 AM
> To: Paolo
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: R: [RT] New validator and propagator infrastructure
>
> On Mon, Oct 22, 2001 at 09:00:41AM +0200, Paolo wrote:
> > Hi Martin!
> > I were thinking of your idea about some month ago... I like that,
but
> > I'd like to add to request parameters/attributes, session attributes
and
> > cookies, the sitemap parameter object to propagate to, or validate
from
> > in these actions.
> >
> > > long [min, max, equals]
> > > double [min, max, equals]
> > > string [max-len, matches-regexp, equals, equals-ignore-case]
> > > date [valid] (probably (min|max)-(day|month|year)
???)
> > > xml [well-formed, valid]
> >
> > I'd like to add the boolean type, too.
>
> yep, good point, but we have to agree what should be considered false
amd what
> true, .., if some web designer who knows how different browsers behave
for
> boolean types of input can provide me with the description I'll be
happy to
> add the functionality...
type="checkbox" is quite simple: absent parameter - false, present
parameter - true.
Value of parameter could be specified via (guess! :)) value attribute:
<input type="checkbox" name="param" value="Yes!"/>
So we could use null as false and not null as true.
Regards,
Vadim
>
> >
> > ByeBYe,
> > Paolo Scaffardi
> > AIRVENT SAM S.p.A.
> >
> >
>
> martin
> --
> 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: R: [RT] New validator and propagator infrastructure
Posted by Martin Man <Ma...@seznam.cz>.
On Mon, Oct 22, 2001 at 09:00:41AM +0200, Paolo wrote:
> Hi Martin!
> I were thinking of your idea about some month ago... I like that, but
> I'd like to add to request parameters/attributes, session attributes and
> cookies, the sitemap parameter object to propagate to, or validate from
> in these actions.
>
> > long [min, max, equals]
> > double [min, max, equals]
> > string [max-len, matches-regexp, equals, equals-ignore-case]
> > date [valid] (probably (min|max)-(day|month|year) ???)
> > xml [well-formed, valid]
>
> I'd like to add the boolean type, too.
yep, good point, but we have to agree what should be considered false amd what
true, .., if some web designer who knows how different browsers behave for
boolean types of input can provide me with the description I'll be happy to
add the functionality...
>
> ByeBYe,
> Paolo Scaffardi
> AIRVENT SAM S.p.A.
>
>
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
R: [RT] New validator and propagator infrastructure
Posted by Paolo <la...@arsenio.net>.
Hi Martin!
I were thinking of your idea about some month ago... I like that, but
I'd like to add to request parameters/attributes, session attributes and
cookies, the sitemap parameter object to propagate to, or validate from
in these actions.
> long [min, max, equals]
> double [min, max, equals]
> string [max-len, matches-regexp, equals, equals-ignore-case]
> date [valid] (probably (min|max)-(day|month|year) ???)
> xml [well-formed, valid]
I'd like to add the boolean type, too.
ByeBYe,
Paolo Scaffardi
AIRVENT SAM S.p.A.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] New validator and propagator infrastructure
Posted by Vadim Gritsenko <va...@verizon.net>.
> -----Original Message-----
> From: Martin Man [mailto:Martin.Man@seznam.cz]
> Sent: Friday, October 19, 2001 1:45 PM
> To: cocoon-dev
> Subject: [RT] New validator and propagator infrastructure
>
> hi all,
> in response to well-known action flood we have seen over past
> days(weeks) I'd like to propose rewrite of validator actions. The
result
> should be one "validator" action which will do the work of all
existing
> validator actions and maybe even more. I think we should do this
before
> 2.0final, because it's not more than cleanup work... and I'm
volunteering to
> do it actually but first to hear some comments...
Glad to hear it :)
Here some suggestions about propagator...
<snip/>
> 2. Propagator (creator)
> -----------------------
> propagators were initialiy intended to ease the creation of
various
> parameters from sitemap, e.g.
>
> <map:act type="propagator">
> <parameter name="store-to" value="session"/> <!-- request,
cookies -->
> <parameter name="value" value="{1}"/>
> </map:act>
How about action with different direction: propagate values from
request/session/cookies into sitemap? I found that this is very useful
action (is this only for me???)
I use this pair of actions (from request/session/cookies into map and
vice versa) heavily to personalize user experience on my site (pure data
publishing). If you are interested I can send you my variants of
actions.
Vadim
> 2.1. Where to store (propagate)
> -------------------------------
> - to session attributes
> - to request attributes
> - to cookies
>
> note that we can store arbitraty objects to session/request
attributes and
> strings to cookies. because brace expressions {name} are actualy
objects taken
> from map, we have to convert them to strings before storing into
cookies, I
> think we anyway use it for strings...
>
>
> I'd like to see your comments and suggestions as well as existing
experience
> with validator/authenticator/propagator actions that we now have for
almost 4
> months. All those changes I'd like to do as soon as RequestContext
will be
> available (and I'm sure it will be ;-)
>
> P.S. note that I left aside formval logischeet which surely will need
the
> appropriate changes as well, please attach comments/experience to this
> topic as well (some new ideas Christian ???)
>
>
> thanx for reading so far,
> martin
> --
> 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org