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=15843.
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=15843.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steven Noels wrote:
Hi folks,
am I correct to assume there is still an issue with Source resolving,
which gets manifested when one uses the SWT in a subsitemap?
I get
source:write src= action=none result=failed
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
Even without mail.jar not present in the lib/optional directory, this
code in this package will still be compiled, leading to compilation
errors. Bernhard, could you please try to fix the problem? If not, I
can take of it tomorrow morning when I wake up.
Thanks,
--
Ovidiu Predescu [EMAIL
Sylvain Wallez wrote:
source:write src= action=none result=failed
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
xmlns:source=http://apache.org/cocoon/source/1.0;The src attribute
could not be resolved and failed to cancel/source:write
The 'src' attribute above is empty. Can't this
cziegeler2003/01/08 00:48:36
Modified:.build.xml
Log:
Removed the include.scratchpad.libs property - include.webapp.libs is sufficient
Revision ChangesPath
1.303 +3 -4 xml-cocoon2/build.xml
Index: build.xml
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=9075.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
However, I still consider the new implementation of
SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
currently in Cocoon) to be a performance burden since in most cases all
component-related operations it performs *will be
Steven Noels wrote:
Sylvain Wallez wrote:
source:write src= action=none result=failed
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
xmlns:source=http://apache.org/cocoon/source/1.0;The src attribute
could not be resolved and failed to cancel/source:write
The 'src' attribute above is
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
Giacomo Pati wrote:
That's a lot!
I've only had about ~180! Do you have deprecation turned on? Than that
will explain alot.
BTW: Someone (IIRC Carsten) had committed Mail... classes that are
compiled against 1.4 version and don't
Sylvain Wallez wrote:
The performance problem is that among all implementations of Source that
I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
SitemapSource and CVSSource), only one actually needs to be disposed
(SitemapSource).
So having a
On Wed, 8 Jan 2003, Ovidiu Predescu wrote:
Even without mail.jar not present in the lib/optional directory, this
code in this package will still be compiled, leading to compilation
errors. Bernhard, could you please try to fix the problem? If not, I
can take of it tomorrow morning when I wake
cziegeler2003/01/08 01:28:02
Modified:.build.xml
Log:
Fixing mock include for scratchpad build
Revision ChangesPath
1.304 +2 -2 xml-cocoon2/build.xml
Index: build.xml
===
RCS file:
Giacomo Pati wrote:
I'm browsing throu the code doing Eclipses 'Organize Imports' all over
I've realized there are a bunch of java file with strange line endings
(always a blank line every other line).
Torsten (Curdt): As it seems that they might be
committed by you would you mind fixing them?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
The performance problem is that among all implementations of Source that
I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
SitemapSource and CVSSource), only one actually needs to be disposed
(SitemapSource).
So having a
On Wed, 8 Jan 2003, Torsten Curdt wrote:
Giacomo Pati wrote:
I'm browsing throu the code doing Eclipses 'Organize Imports' all over
I've realized there are a bunch of java file with strange line endings
(always a blank line every other line).
Torsten (Curdt): As it seems that they
Sylvain Wallez wrote:
Torsten Curdt wrote:
Giacomo Pati wrote:
I'm browsing throu the code doing Eclipses 'Organize Imports' all over
I've realized there are a bunch of java file with strange line endings
(always a blank line every other line).
Torsten (Curdt): As it seems that they might
sylvain 2003/01/08 03:01:39
Added: src/java/org/apache/cocoon/components/source Tag:
cocoon_2_0_3_branch ContextSourceFactory.java
Log:
Fix bug #15279 (writeable source doesn't work with context: URLs)
Revision ChangesPath
No
sylvain 2003/01/08 03:02:18
Modified:src/webapp/WEB-INF Tag: cocoon_2_0_3_branch cocoon.xconf
Log:
Fix bug #15279 (writeable source doesn't work with context: URLs)
Revision ChangesPath
No revision
No revision
1.4.2.5
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=15279.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
sylvain 2003/01/08 03:04:53
Modified:src/java/org/apache/cocoon/components/source/impl
ContextSourceFactory.java
Log:
Fix bug #15279 (writeable source doesn't work with context: URLs)
Revision ChangesPath
1.7 +27 -29
Sylvain Wallez wrote:
Steven Noels wrote:
snip/
and read http://marc.theaimsgroup.com/?t=10399060151r=1w=2
Yeah, I assigned myself this bug and have to fix it ASAP. But so many
things to do ASAP...
Fixed in both branches. In 2.0.4, you need to modify cocoon.xconf :
- remove
On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote:
Well, I'm a bit confused: there is a src attribute on the source:write
element, but only in the status report apparently, and a source:source
element which content should list the filename according to
Jeremy Quinn wrote:
snip/
A bunch of people have reported recently that context:// does not
work as a source:source. TBH I do not remember testing it before
that went into the docs I just assumed it would work, naughty me!
I just fixed it and it does work now ;-)
Sylvain
--
Sylvain
Sylvain Wallez wrote:
Fixed in both branches. In 2.0.4, you need to modify cocoon.xconf :
- remove url-factory 'context'
- add source-handler : protocol
class=org.apache.cocoon.components.source.ContextSourceFactory
name=context/
I'll check it out ASAP (before tomorrow). Thanks!
/Steven
--
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
The performance problem is that among all implementations of
Source that
I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
SitemapSource and CVSSource), only one actually needs to be disposed
Jeremy Quinn wrote:
On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote:
Well, I'm a bit confused: there is a src attribute on the
source:write element, but only in the status report apparently, and a
source:source element which content should list the filename
according
On Wednesday, Jan 8, 2003, at 12:03 Europe/London, Steven Noels wrote:
Jeremy Quinn wrote:
On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote:
Well, I'm a bit confused: there is a src attribute on the
source:write element, but only in the status report apparently, and
a
Steven Noels wrote:
Could this be the case because I'm using this from an auto-mounted
subsitemap? Or that I use a file generating pointing to a pipeline using
cocoon: ?
I checked without cocoon: protocol, no luck either... here's my SWT
input file:
?xml version=1.0 encoding=UTF-8?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Ah, btw you're right that the Source object should return a Collection
instead of an Iterator for the children - I will fix that, too, asap.
Cool. But I'm still not that happy with these methods being on Source
itself.
jeremy 2003/01/08 04:32:22
Modified:src/documentation/xdocs/link livesites.xml
Log:
added www.iniva.org to livesites
Revision ChangesPath
1.11 +1 -0 xml-cocoon2/src/documentation/xdocs/link/livesites.xml
Index: livesites.xml
Jeremy Quinn wrote:
The only thing I can think of at this stage is this:
/profile
/source:fragment
should be :
/profile/source:fragment
like you have :
source:fragmentprofile
at the beginning
SWT will balk on the extra text-node I believe.
No luck. I'm lost on my first
Jeremy Quinn wrote:
On Wednesday, Jan 8, 2003, at 08:48 Europe/London, Steven Noels wrote:
Well, I'm a bit confused: there is a src attribute on the
source:write element, but only in the status report apparently, and a
source:source element which content should list the filename
according
This change seems to introduce a loop at startup. If I revert to revision
1.6 Cocoon starts as usual.
Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK
1.3.1, and ./build.sh clean installscratchpadwar.
Giacomo
On 8 Jan 2003 [EMAIL PROTECTED] wrote:
sylvain
] --
[echo] Apache Cocoon 20030108 [1999-2002]
[echo] --
[echo] Building with Apache Ant version 1.6alpha compiled on January 8 2003
[echo] using build file /home/rubys
Nicola Ken Barozzi wrote:
snip/
I really don't understand much of the heat in this discussion because
I'm not so into it, but I'm happy you guys are and are making progress :-)
Thanks. Actually, the discussions is about many points, one after the
other ;-)
I just wanted to ask for a second
Sam Ruby wrote:
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-01-08/xml-cocoon2.html
[...]
BUILD FAILED
Giacomo Pati wrote:
This change seems to introduce a loop at startup. If I revert to revision
1.6 Cocoon starts as usual.
Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK
1.3.1, and ./build.sh clean installscratchpadwar.
Shame on me, I tested only in the 2.0.x branch
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
snip/
I really don't understand much of the heat in this discussion because
I'm not so into it, but I'm happy you guys are and are making
progress :-)
Thanks. Actually, the discussions is about many points, one after the
other
sylvain 2003/01/08 06:08:05
Modified:src/java/org/apache/cocoon/components/source/impl
ContextSourceFactory.java
Log:
Fix endless loop
Revision ChangesPath
1.8 +14 -2
Giacomo Pati wrote:
This change seems to introduce a loop at startup. If I revert to revision
1.6 Cocoon starts as usual.
Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK
1.3.1, and ./build.sh clean installscratchpadwar.
Fixed.
For an unknown reason, looking up the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities given by File.
And we only
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Fixed.
For an unknown reason, looking up the SourceResolver in the compose()
method of a SourceFactory leads to an endless loop. So the fix consists
in delaying this lookup to the first call to getSource().
I don't know if it's related to
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Cool. But I'm still not that happy with these methods being on Source
itself. What about TraversableSource or HierarchicalSource (I have this
last one ready on my PC with collections) ?
I really don't like all
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then
Sylvain Wallez wrote:
Okay. Let me throw in more arguments ;-)
Great!
How many protocols do we have for which parent and children make sense ?
Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols
such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no
And as far as code cleanliness is concerned, an instanceof test seems
more OOP to me than a isTraversable() method that tells us if is we have
the right to use getParent() and getChildren(). With a separate
interface, these methods do not exist if they do not make sense.
This is a
-Original Message-
From: Stephan Michels [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 3:47 PM
To: [EMAIL PROTECTED]
Subject: RE: Defining Source Interfaces
And as far as code cleanliness is concerned, an instanceof
test seems
more OOP to me than a
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
MHO: It all depends on what a Source is.
1 - If a source is a plug to a URI-based source handler, it should have
children.
2 -If it's a plug to a resource, it should not.
Usually a source is (2), but since we bind the Source to a
AFAIK, internal redirect is only implemented for the interpreted sitemap
(treeprocessor),
and 2.0.x uses the compiled sitemap by default.
From http://xml.apache.org/cocoon/changes.html for 2.0.3:
Handle request forwarding (aka internal redirects) using the
cocoon: pseudo-protocol :
Hi,
what is exactly your configuration problem? What do you want to use/write?
Carsten
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 10:25 PM
To: [EMAIL PROTECTED]
Subject: CVSView block
Hi again,
I made a block
My flowscript is getting big, and I've coded just a fraction of the
functionality of my app.
Is it possible to make it more modular, by including files from a master
script that is the one referred to in the sitemap?
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
Hi all,
I've spend some time now understanding XMLForm and I have looked at
the popup sample from Michael
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15100
I couldn't find a post from Josema Alonso regarding XForms Xindice
that appeared related. Ivelin, which one do you have in mind?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
snip/
And as far as code cleanliness is concerned, an instanceof test seems
more OOP to me than a isTraversable() method that tells us if is we have
the right to use getParent() and getChildren(). With a separate
interface, these methods do not
Sylvain Wallez wrote:
Following Stephen's example, I grep'ed instanceof on the whole 2.1
source base and found... 388 of them !
And how many of them are *not* because of Avalon?
Anyway, I think your arguments are better than mine (sniff).
So, we have a TraversableSource or
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
Anyway, I think your arguments are better than mine (sniff).
So, we have a TraversableSource or HierarchicalSource or ...?
I'm not a native speaker, but the definition of traversable given by
dictionary.com makes me prefer hierarchical...
You
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
[...]
You're totally on track. If you need this action right now, I
would suggest to mimic what's in the DirectoryGenerator, that
makes the assumption that the
About the move() and copy() methods, I don't know if they should be kept
in the new incarnation of this interface.
I don't think that they are important. A copy is a read/write action and
a move a read/write/delete action. We could make an utility class providing
support for it (and this
Sylvain Wallez wrote:
Aren't we all a little bit mad to send dozen of mails for a bunch of
methods ;-P
And the real fun has just started: finding the correct name of something!
Yuppie!
BTW: How are our current blocks called now? (no, no, please don't take this
as serious).
Carsten
Stephan Michels wrote:
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
Anyway, I think your arguments are better than mine (sniff).
So, we have a TraversableSource or HierarchicalSource or ...?
I'm not a native speaker, but the definition of traversable given by
dictionary.com makes me
On Mon, 23 Dec 2002, Stefano Mazzocchi wrote:
I know almost everybody is idle for the holydays, but I want to reply to
this before I forgot :)
Unfortunaltly my idle time is over and im now back in freezing
Germany. Hmmm...
Michael Melhem wrote:
Hi,
Ok, here is a little rant on
cziegeler2003/01/08 08:07:38
Modified:src/java/org/apache/cocoon/components/source/impl
SitemapSource.java
Log:
Minor performance update
Revision ChangesPath
1.29 +12 -6
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Aren't we all a little bit mad to send dozen of mails for a bunch of
methods ;-P
And the real fun has just started: finding the correct name of something!
Yuppie!
BTW: How are our current blocks called now? (no, no, please don't take this
as
About the move() and copy() methods, I don't know if they should be kept
in the new incarnation of this interface.
:-/ not another MoveableSource ;-)
ROFL !!!
;-)
Seriously, are these methods of real use ?
I thought that these methods could be a good start for a cms
webportal. Not?
Stephan Michels wrote:
About the move() and copy() methods, I don't know if they should be kept
in the new incarnation of this interface.
I don't think that they are important. A copy is a read/write action and
a move a read/write/delete action. We could make an utility class providing
support
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
Giacomo Pati wrote:
This change seems to introduce a loop at startup. If I revert to revision
1.6 Cocoon starts as usual.
Sylvain, is this change running on your side? We used Tomcat 4.1.18, JDK
1.3.1, and ./build.sh clean installscratchpadwar.
giacomo 2003/01/08 08:27:13
Modified:src/blocks/batik/java/org/apache/cocoon/serialization
SVGSerializer.java
Log:
fixed a todo. God! Eclipse even finds those // TODO lines
Revision ChangesPath
1.2 +4 -3
cziegeler2003/01/08 08:35:13
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
Log:
Turning of smart caching :( as it doesn't work...
Revision ChangesPath
1.12 +17 -12
Giacomo Pati wrote:
And here is the definitiv answer from the avalon team:
Remember that this is component-oriented programming (COP) and
not OOP.
:)
C'mon. LifecycleHelper is the master batch of COP and not a normal
class!
:) Yes, I know - but if you look at most instanceof
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
The problem is, if you are using getInputStream/getOutputSteam to copy
a file in a slide repository, that all metadata informations get lost. On
the other hand, if you are using an external SourceUtil to copy a file,
On Wed, 8 Jan 2003, Ugo Cei wrote:
My flowscript is getting big, and I've coded just a fraction of the
functionality of my app.
What is big for you in terms of lines?
I thought a flowscript would be small and logic is modularized into Java
classes.
Giacomo
THANK YOU!
I just switched to the interpreted sitemap and map:redirect-to cocoon:/someuri/
does indeed work, but it took a while to get everything else working again.
In cocoon.xconf, why is the file attribute of sitemap ignored when using the
interpreted sitemap implementation? Is there a new
cziegeler2003/01/08 08:42:30
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
Log:
Turning on smart caching as it works now :)
Revision ChangesPath
1.13 +6 -5
Giacomo Pati wrote:
On Wed, 8 Jan 2003, Ugo Cei wrote:
My flowscript is getting big, and I've coded just a fraction of the
functionality of my app.
What is big for you in terms of lines?
The one I'm currently working on is about 300 lines and I'm starting to
feel unconfortable about it. The
On Wed, Jan 08, 2003 at 04:12:12PM +0100, Carsten Ziegeler wrote:
Hi,
what is exactly your configuration problem? What do you want to use/write?
Carsten
I need to configure the root path for the generator, at construction
time, so that it processes the (mandatory) path parameter (given
Giacomo Pati wrote:
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
What do you think about the ModifiableSource in Excalibur? (That should be
the replacement for WriteableSource - please let *me* win this time ;) )
Sylvain is hard to beat somtimes, I can tell from
Hello,
we are thinking how a multi-line result from an SQL-query can be passed
efficiently from the logic layer to the flow layer.
One possibility, that currently works, is to build a List of Java objects
(one for each row) and access this List via jxpath in the view.
In the view we then have
Hi Ugo,
On Wednesday, Jan 8, 2003, at 07:43 US/Pacific, Ugo Cei wrote:
My flowscript is getting big, and I've coded just a fraction of the
functionality of my app.
Is it possible to make it more modular, by including files from a
master script that is the one referred to in the sitemap?
The
On Wednesday, Jan 8, 2003, at 01:26 US/Pacific, Giacomo Pati wrote:
On Wed, 8 Jan 2003, Ovidiu Predescu wrote:
Even without mail.jar not present in the lib/optional directory, this
code in this package will still be compiled, leading to compilation
errors. Bernhard, could you please try to
On Wednesday, Jan 1, 2003, at 04:46 US/Pacific, Jeremy Quinn wrote:
On Wednesday, Jan 1, 2003, at 02:44 Europe/London, David Crossley
wrote:
I get the same problem on Linux with Java-1.3.1
./build.sh -Dinclude.webapp.libs=yes webapp
Well that is interesting!
I was seriously beginning to
Steven Noels wrote:
No luck. I'm lost on my first adventure with the SWT. See, Sylvain? ;-)
Ah - thanks to Bruno, I think I found out.
In 2.0.3/4/5, the syntax of the SWT (still in scratchpad then) should be:
source:write xmlns:source=http://apache.org/cocoon/source/1.0;
Steven Noels wrote:
In 2.0.3/4/5, the syntax of the SWT (still in scratchpad then) should be:
source:write xmlns:source=http://apache.org/cocoon/source/1.0;
src=gump-profile.xml
...
/source:write
source:fragment isn't needed, too.
And now, I'll keep my mouth shut!
/Steven
--
Steven
We get the same error on Win2k + java1.3.1 but at another position during
the build process.
What's the reason for this ant problem?
Regards,
Reinhard
-Original Message-
From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 7:44 PM
To: [EMAIL PROTECTED]
By increasing the amount of heap space allocated to the JVM, the build
works fine now. I've added the -Xmx512mb parameter to the java
invocation in tools/bin/ant, the last line in this file. A similar
thing has to be done in tools/bin/ant.bat. I can check-in this change
if it fixes the build
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=15900.
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=15900.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
The current flow code has a problem when passing Java object from the
flow to the view using the sendPage and sendPageAndWait functions: all
the values in the map that is passed as the second argument to the
function get converted to strings. This makes it impossible to access
field values
Ovidiu Predescu wrote:
The 'cocoon' object has a load() function, which takes as parameter the
name of the script you want to load. Please let me know if this works
for you.
If I put a list of cocoon.load instructions at the beginning of a
script, will they be executed when the file is first
Parameters passed from the sitemap to the flow functions are not
strings. Here's an example:
map:match pattern=test
map:call function=test
map:parameter name=param value=testval/
/map:call
/map:match
function test(param) {
if (param == testval) { /* THIS TEST FAILS! */ }
if ( +
On Wednesday, Jan 8, 2003, at 12:55 US/Pacific, Ugo Cei wrote:
Ovidiu Predescu wrote:
The 'cocoon' object has a load() function, which takes as parameter
the name of the script you want to load. Please let me know if this
works for you.
If I put a list of cocoon.load instructions at the
cziegeler2003/01/08 13:48:02
Modified:lib jars.xml
Added: lib/core avalon-framework-4.1.3.jar logkit-1.1.jar
Removed: lib/core avalon-framework-20020627.jar logkit-20020529.jar
Log:
Updating jars for avalon framework and logkit to latest official releases
Torsten Curdt wrote:
Sylvain Wallez wrote:
Torsten Curdt wrote:
Giacomo Pati wrote:
I'm browsing throu the code doing Eclipses 'Organize Imports' all over
I've realized there are a bunch of java file with strange line endings
(always a blank line every other line).
Torsten (Curdt): As it
Hi all,
yesterday, we've released the 1.0 version of xReporter, our open source
Avalon/Cocoon-based database reporting framework, available from
http://xreporter.cocoondev.org/
xReporter consists of 2 main components:
* an Avalon Phoenix-based query server, which is configured through
ovidiu 2003/01/08 17:48:55
xml-cocoon2/src/java/org/apache/cocoon/components/flow/schedulerwrapper - New
directory
--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
ovidiu 2003/01/08 17:49:48
Added: src/test/anteater flowscriptReload.xml
Log:
Anteater test for flow script reloading.
Revision ChangesPath
1.1 xml-cocoon2/src/test/anteater/flowscriptReload.xml
Index: flowscriptReload.xml
crossley2003/01/08 19:13:55
Modified:src/webapp/WEB-INF/entities sitemap-v06.rng
Log:
Sync with Forrest.
Revision ChangesPath
1.3 +20 -0 xml-cocoon2/src/webapp/WEB-INF/entities/sitemap-v06.rng
Index: sitemap-v06.rng
crossley2003/01/08 19:14:10
Modified:src/webapp/resources/entities Tag: cocoon_2_0_3_branch
sitemap-v06.rng
Log:
Sync with Forrest.
Revision ChangesPath
No revision
No revision
1.1.2.3 +20 -0
1 - 100 of 130 matches
Mail list logo
