Thanks Unico!
Carsten
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 6:59 PM
To: [EMAIL PROTECTED]
Subject: svn commit: rev 55618 - cocoon/trunk/src/blocks/axis/conf
Author: unico
Date: Tue Oct 26 09:58:44 2004
New
We can simply use the CocoonServiceSelector. I just fixed it.
Thanks!
Carsten
-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 27, 2004 12:26 AM
To: [EMAIL PROTECTED]
Subject: Re: svn commit: rev 55059 - in
Bertrand Delacretaz wrote:
Le 26 oct. 04, à 21:56, Jorg Heymans a écrit :
Both, but many of us agree that the biggest problem now is accessibility
(both from the user's and from the writer's point of views) of the docs.
point taken, but i don't share that feeling. I trust my searching skills
On 27 Oct 2004, at 07:53, Reinhard Poetz wrote:
One question to the strict cleaning. IIRC Steven's presentation you
use HtmlArea at the client. So I guess that the HtmlCleaner is in some
way optimized (at least testet) with it and it should work fine with
it. I mean that it doesn't swallow
Forwarding it to dev mailing list.
Does anybody know a solution for the problem described at
http://marc.theaimsgroup.com/?t=10887446701r=1w=4 (or for the most
important things below).
I suggested to either point out the wrong cast to the Tomcat community
or to let CompilingClassLoader
Luigi Bai wrote:
On Tue, 27 Oct 2004, David Crossley wrote:
Luigi Bai wrote:
Stefano Mazzocchi wrote:
Maybe it is more precise to say When shit works /mostly/ well
The
presence of a large number of outstanding Bugzilla issues,
especially ones
with [PATCH]es attached, implies that things
Steven Noels wrote:
On 27 Oct 2004, at 07:53, Reinhard Poetz wrote:
One question to the strict cleaning. IIRC Steven's presentation you
use HtmlArea at the client. So I guess that the HtmlCleaner is in
some way optimized (at least testet) with it and it should work fine
with it. I mean that
Stefano Mazzocchi wrote:
David Crossley wrote:
So when a real, potentially damaging, issue arises we will have no
way to sensibly handle it.
It has been working fine so far and I see no evidence of things changing.
Even if I'm more inline with Stefano's way of seeing things and have a
natural
On Wed, 2004-10-27 at 10:13 +0200, Reinhard Poetz wrote:
Steven Noels wrote:
On 27 Oct 2004, at 07:53, Reinhard Poetz wrote:
One question to the strict cleaning. IIRC Steven's presentation you
use HtmlArea at the client. So I guess that the HtmlCleaner is in
some way optimized (at
On 27 Oct 2004, at 10:21, Sylvain Wallez wrote:
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/src/
documentation/content/xdocs/bylaws.xml
[2] http://wiki.apache.org/excalibur/Bylaws
This is where mostly me and David left it at:
Bertrand Delacretaz wrote:
Le 26 oct. 04, à 23:36, Helma van der Linden a écrit :
...G4. Make submitting documentation a more straight forward process.
I haven't yet looked at the ins and outs of the xdocs, but I know from
the times I tried to find the documentation in the checked out tree
that
...So we would have two separate instances of Cocoon (or Forrest).
One is the staging server, which is the head. The other is the
live site, which uses the current-docs tag...
Not necessarily two instances, could be one IMHO, with URLs selecting
either the relased docs or other tags (and
Hi,
yes this handler does the work. Now, I would prefer to have a new
method that searches in the attributes of the instance and then
in the coplet data - this would provide compatibility.
Carsten
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October
On 26 Oct 2004, at 20:46, Bertrand Delacretaz wrote:
So I cannot refrain from sharing this idea, although I have no code to
back it up yet...
Similarly, however not even _hinting_ that this is something I'd want
to push myself, your set of goals and techniques still somehow teased
me in doing a
Vadim Gritsenko wrote:
Unico Hommes wrote:
Now only one release blocker remains: NPE in
AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's
mimeType in this particular case, as per:
public String getMimeType() {
Context ctx =
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 56
On Wed, 27 Oct 2004, Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Now only one release blocker remains: NPE in AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's
mimeType in this particular case, as per:
public String
Luigi Bai wrote:
On Wed, 27 Oct 2004, Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Now only one release blocker remains: NPE in
AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's
mimeType in this particular case, as per:
Luigi Bai wrote:
I would like to consider allowing the mime-type to be set during
processing, perhaps even as late as after endDocument().
No, that's against Cocoon Way. I'd even say, *all* headers should be set
*before* startDocument, during pipeline assembly setup stages. What's
happening in
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Now only one release blocker remains: NPE in
AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's
mimeType in this particular case, as per:
public String getMimeType() {
On Wed, 27 Oct 2004, Vadim Gritsenko wrote:
Luigi Bai wrote:
I would like to consider allowing the mime-type to be set during
processing, perhaps even as late as after endDocument().
No, that's against Cocoon Way. I'd even say, *all* headers should be set
*before* startDocument, during pipeline
On Wed, 27 Oct 2004, Unico Hommes wrote:
I would like to consider allowing the mime-type to be set during
processing, perhaps even as late as after endDocument(). The reason for
this is: I store images in XML documents as Base64 encoded data, and its
element tag looks like this:
image
Luigi Bai wrote:
On Wed, 27 Oct 2004, Unico Hommes wrote:
I would like to consider allowing the mime-type to be set during
processing, perhaps even as late as after endDocument(). The reason
for this is: I store images in XML documents as Base64 encoded data,
and its element tag looks like
On Wed, 27 Oct 2004, Unico Hommes wrote:
Luigi Bai wrote:
Exactly. This is the problem with delaying the setting of the mime type.
For the general case we'd always have to buffer the whole response which
isn't practical.
Well, according to the Servlet spec, you really should set ContentType
Luigi Bai wrote:
On Wed, 27 Oct 2004, Unico Hommes wrote:
A Serializer will never deal with WrappedEnvironments AFAICS. Internal
xml pipeline processing is pipeline minus Serializer.
Hm, don't think so. Example:
map:match pattern=dynamic.jpg
map:generate src=foo.svg/
map:seialize
Unico Hommes wrote:
I've also deprecated
ActionRequest.getPortletInputStream in the portlet environment.
It is unstable block; and this method was not exposed via interface at all; so I
just went ahead and re-named the method in 2.1.X branch. No deprecation
necessary in this case.
Vadim
Jonas Ekstedt wrote:
Hello
I have created a widget framework that I would like to donate to Cocoon
(if you want it). I think it has several advantages to the current
Cocoon Forms framework in that it is more straightforward to use and
that it is easier to extend.
Interesting stuff. I'll take the
Luigi Bai wrote:
On Wed, 27 Oct 2004, Unico Hommes wrote:
Luigi Bai wrote:
Exactly. This is the problem with delaying the setting of the mime
type. For the general case we'd always have to buffer the whole
response which isn't practical.
Well, according to the Servlet spec, you really should
On Wed, 27 Oct 2004, Unico Hommes wrote:
Luigi Bai wrote:
And Cocoon already has shouldSetContentLength(), which tells the pipeline
that at least ContentLength happens later in the processing (and of
course the output has to be buffered). If that is not set, the general
case is to stream
Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
Now only one release blocker remains: NPE in
AbstractEnvironment.release()
No, not exactly. As I see it, ResourceReader should return Source's
mimeType in this particular case, as per:
public String
hi people
ihave a cform sample where the form work as a navigator into a
tree-structured element (composite pattern)
i would like to see this sample in cforms sample area
what i have to do is to add a PATCH entry to bugzilla with sample's files
or i have to modify existings files (sitemap,
Jorg Heymans wrote:
First of all, thanks Luigi for bringing up something that has been on my
mind for a long time! Cocoon's patch queue is nothing to be proud of to
be honest, both in size and age.
The only way to get an overworked committer off the hook in the long run
is to guide and nurture
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Two points;
* Gump is about continuous integration, i.e. always trunk, right?
so far ;-)
And our build does not need version information too. Then,
who needs it?
My idea is the following: gump should be *both* a build system and a
continous
Luigi Bai wrote:
And the issue of poor overworked committers can be partially
alleviated by increasing the number of people deputized to commit bug
fixes. This will likely get even easier to administer when real blocks
become a reality; then individuals can be deputized per block (they
can be
Frédéric Glorieux wrote:
For sysadmin, it may be important for the cocoon servlet to be totally
read-only, even logs. I used to try to run a same cocoon in parallel in
different servlet contexts (same JVM, same tomcat, different URIs). Logs
were quite funny to read but a bit broken. For a fast
Leszek Gawron wrote:
May I ask what is the current procedure to become a commiter? From what
I've seen on the list the only way to become one is to be introduced by
another commiter? Is that right?
Yes. Read more here
http://www.apache.org/foundation/how-it-works.html#meritocracy
Vadim
Leszek Gawron said:
May I ask what is the current procedure to become a commiter? From what
I've seen on the list the only way to become one is to be introduced by
another commiter? Is that right?
With great power comes great responsibility
or
From those to whom much is given, much is
May I ask what is the current procedure to become a commiter? From what
I've seen on the list the only way to become one is to be introduced by
another commiter? Is that right?
Yepp!
Contribution in discussions, code and/or documentation
qualify for a nomination. If people are active and
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31751.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31751.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31676.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Jonas:
I found the lecture interesting. Showed me that we need to put more effort
in documenting the CForms framework. You are making some assertions about
the CForms framework that are no exactly true
Please don't take bad the comments between lines, because we are
learning. ;-)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31676.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi:
There is a new version of HyperSonic database: 1.7.2. It is already
committed in cocoon 2.2. I delayed the update of the branch because there
are some incompatibilities between 1.7.1 applications and 1.7.2:
snip src=http://hsqldb.sourceforge.net/web/changelog.html;
As a result, 1.7.2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30849.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30849.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I don't get a vote, but unless there is some major fix in 1.7.1 I would
vote not to do this in 2.1.6. Instead, I would publish this as a
release note in 2.1.6 that the upgrade will take place in 2.1.7.
I would also complain to the HSQLDB folks about making incompatible
changes in maintenance
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25951.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27176.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27176.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Hi:
There is a new version of HyperSonic database: 1.7.2. It is already
committed in cocoon 2.2. I delayed the update of the branch because there
are some incompatibilities between 1.7.1 applications and 1.7.2:
What are we getting with the upgrade? I see the stuff in the
Ralph Goers wrote:
I don't get a vote, but unless there is some major fix in 1.7.1 I would
vote not to do this in 2.1.6. Instead, I would publish this as a
release note in 2.1.6 that the upgrade will take place in 2.1.7.
You may noy have a vote, but you'll always have a say, and people will
Le 28 oct. 04, à 01:39, Antonio Gallardo a écrit :
...Question:
In Cocoon 2.1.6-dev: Upgrade HSQLDB to version 1.7.2?
...
[X ] I don't care.
or rather trust you to upgrade it the corresponding samples still work
after the upgrade.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
54 matches
Mail list logo
