Christoph,
Could you add an entry at Bugzilla and create an attachement containing
your generator and an example showing its features?
If you do it I will take care of it and add it to the scratchpad.
Cheers,
Reinhard
-Original Message-
From: Christoph Gaffga [mailto:[EMAIL
Christopher Oliver wrote:
Unfortunately I think 2.1.1 contains a Rhino regression I temporarily
introduced while trying to fix bug 22513 which will cause any scripts
with nested functions to fail. This includes some of the flow samples
like PetStore and JXForms.
Duh. Showstopper?
/Steven
--
Christopher Oliver [EMAIL PROTECTED] wrote:
Unfortunately I think 2.1.1 contains a Rhino regression I temporarily
introduced while trying to fix bug 22513 which will cause any scripts
with nested functions to fail. This includes some of the flow samples
like PetStore and JXForms.
IMO we are
Barzilai Spinak wrote:
Christopher Oliver wrote:
BarZ,
Feel free to submit patches to JXForms, for example for
selectBoolean. Nobody is responsible for JXForms or other Cocoon
development per se. It's voluntary.
Well, thanks for your confidence hehe.
I may do just that when I feel more
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Tuomo L wrote:
It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that in-memory zip-file to the target-dir.
Christopher Oliver wrote:
BTW that flowscript code was written with the intention of supporting
multi-page Woody forms with automated back/forward navigation as in
JXForms. However, when I looked into implementing this I discovered
that Woody forms cannot be presented in multiple pages because
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion on the dev list, and that
On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
Bruno Dumon wrote:
(catching up on block discussions...)
On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
snip/
Implementation Phases
-
Phase 1: definition of the contract between the block manager inside
On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:
Bruno Dumon wrote:
On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
But this brings up another point - what to do if the wiring.xml and
others is deleted? Presumably, all blocks are uninstalled in this
state, but what does this
From: Steven Noels
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion
Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a écrit
:
...Would it be enough to extend our Anteater scripts (see Guido's
mail) and
add Anteater to our codebase and include it automatically to our build
system? ...
certainly a Good Thing it tests are not too hard to write -
JBoss has its own concurrent.jar, what's loaded prior to Cocoon's jar. I
tried to patch JBoss libs using jboss.patch.url pointing to Cocoon's
concurrent.jar (it should at least work similar to endorsed dirs), but first
it does not work and second one webapp should not influence the server.
At
And I know why I asked for a better option: I get now
java.lang.LinkageError: duplicate class definition:
org/apache/xml/dtm/ref/DTMManagerDefault
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
From: Joerg Heinicke
And I know why I asked for a better option: I get now
java.lang.LinkageError: duplicate class definition:
org/apache/xml/dtm/ref/DTMManagerDefault
snip/
as similar described by Sylvain at
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem.
He suggests
In the CLI code, there is a variable called suri. I've never been able
to work out what its name means, and thus what its purpose is. Can
anyone explain?
Also, there are points in the code where a URI is deparameterized and
then reparameterized. What is the point in this?
Regards, Upayavira
Jeff Turner wrote:
I'd be interested to know if any other users experience this problem, and
also why Cocoon needs a recompiled FOP jar in the first place.
Me too, as I'm experiencing the exact same problem as you described,
with jimi.jar on the classpath. Even worse, there isn't a supported
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Tuomo L wrote:
On Tue, 9 Sep 2003, Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Tuomo L wrote:
It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that
Could you add an entry at Bugzilla and create an attachement containing
your generator and an example showing its features?
If you do it I will take care of it and add it to the scratchpad.
I have added it to bugzilla, bug #23061.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061)
Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
...
I also considered recording the wire-id instead of the uri for
connections between blocks - what are the arguments for each?
connection was out of the blue using the wiring metaphore. Other
options? Free association:
Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:
Bruno Dumon wrote:
On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
But this brings up another point - what to do if the wiring.xml and
others is deleted? Presumably, all blocks are uninstalled in this
state, but what
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steven Noels [EMAIL PROTECTED] wrote:
3) Given the breakage in the Rhino stuff, and the lack of serious
testing on the 2.1.1 release, I would refrain from announcing 2.1.1
How about putting a hotfix on the dist site like Tomcat is doing
http://nagoya.apache.org/mirror/jakarta/tomcat-4/binaries/
Tuomo L wrote:
Isn't the uploaded file stored in memory at somepoint anyway,
No.
and then dumped on disk?
No. Cocoon should be able to process files which are larger than amount
of memory on a box.
After the request/response is complete, the memory is
released, right?
Yes.
Vadim
On Wed, Sep 10, 2003 at 12:59:07PM +0200, Steven Noels wrote:
Jeff Turner wrote:
I'd be interested to know if any other users experience this problem, and
also why Cocoon needs a recompiled FOP jar in the first place.
Me too, as I'm experiencing the exact same problem as you described,
The exception below was the reason for building our own FOP and not taking
the released fop.jar. Immediately before releasing Cocoon 2.1 somebody told
us that Cocoon's FOP and Batik are incompatible, but a rebuild of FOP using
Cocoon's Batik helped, so I did it too and committed the fop.jar.
I
Joerg Heinicke wrote:
I know FOP should be built with JAI and JIMI and I thought I have done
it. Sorry for any inconvenience.
No problem - it brings a sense of reality about our user base and their
upgrade frequency, when we discover these things ourselves only after a
few weeks or so. ;-)
Hmm, I read it the other way around: This is exactly the error that can
occur when using ParanoidCocoonServlet. Does anybody know more about such
issues?
Joerg
Reinhard Poetz wrote:
From: Joerg Heinicke
And I know why I asked for a better option: I get now
java.lang.LinkageError: duplicate
Geoff Howard wrote:
Tuomo L wrote:
On Tue, 9 Sep 2003, Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Tuomo L wrote:
It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be
--- Sylvain Wallez [EMAIL PROTECTED] wrote:
Error-handlers are not invoked on internal requests, which is what the
flow uses behind sendPage[AndWait](). In that case, the exception are
propagated.
How do you catch these exceptions in a flowscript? I tried a simple
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Upayavira wrote:
Don't know if you've seen Carsten Ziegler and Matthew Langham's book
on Cocoon. It cover's how to add protocols/sources to Cocoon (on
2.0.4, but once you've understood that, doing it on 2.1 shouldn't be
hard).
It basically consists in writing an implementation of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steven Noels wrote:
Hi folks,
forgive me for putting on my BOFH hat, while making the following
observations...
1) We suck at freezing and stabilizing the codebase prior to releases.
I would suggest that, from now on, the Release Manager puts forward a
release date after discussion on the dev
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tuesday, September 9, 2003, at 03:30 PM, Joerg Heinicke wrote:
Ok, done. The vote for the change was unambiguous. Please review my
commits and change the code if necessary.
Done. your changes mirrored mine for the most part, and I just layered
a few more on top (complete eviction of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
The flow uses an internal redirect to handle an external request. This
means that the propagated exception is only catched by the top-level
Cocoon object which outputs the default error page (if configured to
do so). So we can say that the behaviour of not executing error
Sylvain Wallez wrote:
There are 2 solutions to solve this :
1/ apply the same policy for internal redirects than the one that
was active before the redirect (i.e. handle errors on internal
redirects resulting from external requests)
This totally makes sense.
2/ let the user choose the
Anybody against completely removing
org.apache.cocoon.components.xpath.*, together with jaxen, from the
deprecated classes?
Vadim
I propose Antonio Gallardo and Tony Collen to be Cocoon committers.
They have both been contributing lots of stuff and discussion
on both cocoon-dev and cocoon-users since mid-2002.
Here is my +1 for both.
--David
Vadim Gritsenko wrote:
Upayavira wrote:
In the CLI code, there is a variable called suri. I've never been
able to work out what its name means, and thus what its purpose is.
Can anyone explain?
Also, there are points in the code where a URI is deparameterized and
then reparameterized. What
45 matches
Mail list logo
