Hi Gianugo,
I'm personnaly not the one with the OSWorkflow experience. I'll ask the right person
to post his experiences. Arje
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Posted At: Monday, March 01, 2004 7:42 PM
Posted To: Cocoon Dev List
Conversation:
Christoph Gaffga wrote:
The idea is to set JSDK 1.4 as the minimum supported JDK supported for the
next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but
seems like few people is using it.
but what about the maximum support JDK? I tried to compile with 1.5beta, but
it
Reinhard Pötz dijo:
Did you solve your problems with running ant using JDK? I proposed to
run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the
javac task of Ant. Did you try this?
It would be fine to already include it in the build system. Soon or later
we will need to make the
Antonio Gallardo wrote:
Reinhard Pötz dijo:
Did you solve your problems with running ant using JDK? I proposed to
run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the
javac task of Ant. Did you try this?
It would be fine to already include it in the build system. Soon or
Okay, Simon, sorry for my delay in replying.
Here's my idea of what I'd like to see.
Firstly, I'd ___love___ to see a really thin GUI, with no editors (or a
really cut down notepad style editor) living within Cocoon CVS, and
packaged with Cocoon .This GUI should make use of as much of Cocoon's
Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/03 11:47:35
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
clean up: removed unused code (for reverting changes we have CVS, so
please remove old
Sylvain Wallez dijo:
Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/03 11:47:35
Modified:src/blocks/woody/java/org/apache/cocoon/woody/binding
RepeaterJXPathBinding.java
Log:
clean up: removed unused code (for reverting changes we have
On 04.03.2004 09:31, Sylvain Wallez wrote:
changed isNullAllListElements() = isAnyListElementNotNull(): the
duplicate negation at usage time breaks my brain ;-)
This depends of the POV you see it:
isNullAllListElements() - This is not a negation. It check if :
All elements on the List are
In fact we can call it:
isValidKey(...) --- I prefer this one over the below name.
isValidUniqueRowId(...)
The other names are too specific to what the function do. Sometimes it is
good to call the functions by what solve and not by how is the internal
implementation (using List, Set or
On 04.03.2004 03:06, Antonio Gallardo wrote:
Antonio, I guess you are the only one using it at the moment. Can you
test it please?
I tested it before committing. I can not assure it is totaly bug free.
What I can said is I will use it in many places. If there is a bug it will
be showed.
It was
Joerg Heinicke dijo:
On 04.03.2004 03:06, Antonio Gallardo wrote:
Antonio, I guess you are the only one using it at the moment. Can you
test it please?
I tested it before committing. I can not assure it is totaly bug free.
What I can said is I will use it in many places. If there is a bug it
Did you solve your problems with running ant using JDK? I proposed to
run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the
javac task of Ant. Did you try this?
no, I haven't tried yet. I just started build with JAVA_HOME pointing to 1.5
and getting an error like:
Buildfile:
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=27432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Hi:
How to test drive the current JCS store implementation?
An example configuration is now being patched in automatically by the
build system. Look for JCS keyword and uncomment the configuration.
I ran into a nasty circular dependency with the RepositorySource and
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=27432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Hi:
How to test drive the current JCS store implementation?
Hmm, I can't seem to get past this NPE:
Caused by: java.lang.NullPointerException
at java.io.Reader.init(Unknown Source)
at java.io.InputStreamReader.init(Unknown Source)
at
[EMAIL PROTECTED] wrote:
antonio 2004/03/03 23:01:56
Modified:lib jars.xml
Log:
Updated POI to 2.5-final-20040302
Is name of the JAR file coming from POI project? It's weird to see
poi-2.5-final-20040302 instead of poi-2.5 as for other projects.
Vadim
Wow, that's a nice one :)
Now, I think passing this debug information into the Parameters is not
the correct way to go. It can cause - as we see - problems and in
addition this is an incompatible change! So all sitemap components
that are iterating over the parameters object are affected by this
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :
...I think, we should disable this feature for now and find a better
and compatible way
Wouldn't just changing the header name from
org.apache.cocoon.sitemap/Location to something like
X-Cocoon-debug-sitemap-location
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten
Ziegeler a écrit :
...I think, we should disable this feature for now and find
a better
and compatible way
Wouldn't just changing the header name from
org.apache.cocoon.sitemap/Location to
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 15:01 Europe/Zurich, Carsten
Ziegeler a écrit :
Bertrand Delacretaz wrote:
...Using a known prefix like X-Cocoon-debug- also makes
it easy to
filter out these headers when needed.
But then you have to change every component
I didn't test it :) Perhaps the JCS version I put into the CVS
from yesterday doesn't work? Or I did something wrong file I
refactored the code a little bit?
Corin, which version of JCS did you use?
Carsten
-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent:
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
...Yes, so if someone knows where this is used/useful we can perhaps
think about an alternative.
It is used to add location info to Exceptions, for example in
o.a.c.matching.AbstractRegexpMatcher.preparedMatch()
(search for
Wouldn't just changing the header name from
org.apache.cocoon.sitemap/Location to something like
X-Cocoon-debug-sitemap-location fix the problem?
Perhaps in this special case, I don't know, perhaps Lars can answer this.
Just renaming might solve it, but I would not be happy with this
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 15:07 Europe/Zurich, Carsten Ziegeler a écrit :
...Yes, so if someone knows where this is used/useful we can perhaps
think about an alternative.
It is used to add location info to Exceptions, for example in
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=27440.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
agreed, 'nice one' was my reaction also :-)
I ran into this already some weeks ago, probably should have reported it
on the mailling list. It is in my upgrade 'report' however :-), but I
didn't consider it a bug or so. We're using a pagination component that
started behaving really weird
It was a long time since I last used the Avalon instrumentation stuff,
but it just seems like it's not working anymore. I'm following the
provided instructions under tools/instrumentation, something is
listening on port 1 as expected but the GUI seems just to sleep in a
Not connected
Actually, I have a requirement to do exactly that, so if anyone has already
done it I'd happily use the code.
Ralph
-Original Message-
From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 04, 2004 7:53 AM
To: [EMAIL PROTECTED]
Subject:Instrumentation,
Gianugo Rabellino wrote:
It was a long time since I last used the Avalon
instrumentation stuff, but it just seems like it's not
working anymore. I'm following the provided instructions
under tools/instrumentation, something is listening on port
1 as expected but the GUI seems just
Carsten Ziegeler wrote:
Yes, JMX is imho the way to go, so a general +1. I don't have
much knowledge of JMX, but I would assistent and help in such
an effort whereever I can.
The simple question is only, which version we would use as base,
I would suggest 2.2.
It really depends on how far we are
Gianugo Rabellino wrote:
Carsten Ziegeler wrote:
Yes, JMX is imho the way to go, so a general +1. I don't have much
knowledge of JMX, but I would assistent and help in such an effort
whereever I can.
The simple question is only, which version we would use as base, I
would
I second this opinion. Our development is focused on using 2.1 since that
is what is available. Although we are many months from deploying I wouldn't
want to make a switch to 2.2 that late in the development. We have a
requirement to be able to instrument as much as possible, so getting a
handle
There were some posts on February 4 that indicated that excalibur-instrument
was a good way to get info on the pools was excalibur-instrument-manager
(and presumably excalibur-instrument). Your earlier post indicated that
avalon instrumentation is dead. Are these the same things?
Ralph
Sorry to put my noose in this discussion :-)
-Mensagem original-
De: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
I'm no JMX expert at all, but I understand that basic JMX support can be
easily piggybacked on existing code, as long as you're basically happy
with monitoring and small
Ralph Goers wrote:
I second this opinion. Our development is focused on using 2.1 since that
is what is available. Although we are many months from deploying I wouldn't
want to make a switch to 2.2 that late in the development. We have a
requirement to be able to instrument as much as possible,
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
I'm no JMX expert at all, but I understand that basic JMX support can be
easily piggybacked on existing code, as long as you're basically happy
with monitoring and small management tasks: more important needs might
require significant
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=27440.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten
Ziegeler a écrit :
...I think, we should disable this feature for now and find
a better
and compatible way
Wouldn't just changing the header name from
Gianugo Rabellino wrote:
Carsten Ziegeler wrote:
Yes, JMX is imho the way to go, so a general +1. I don't have
much knowledge of JMX, but I would assistent and help in such
an effort whereever I can.
The simple question is only, which version we would use as base,
I would suggest 2.2.
It
Gianugo Rabellino wrote:
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
I'm no JMX expert at all, but I understand that basic JMX support can
be easily piggybacked on existing code, as long as you're basically
happy with monitoring and small management tasks: more important
needs
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
-Mensagem original-
De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Just keep in mind that everytime you do code generation IDEs that need
to compile classes to operate (like Eclipse or Idea) choke big time.
Haven't had this
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 4 mars 2004, à 14:37 Europe/Zurich, Carsten Ziegeler a écrit :
...I think, we should disable this feature for now and find
a better
and compatible way
Wouldn't just changing the header
-Mensagem original-
De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
But this gets pretty hairy with CVS and a distributed workgroup, believe
me.
Well, we use CVS. The two basic rules was:
- You do not upload generated code to CVS
- You do not upload generated code to CVS!!
:-)
But it
I can't figure out how to call another component. In my case, I want to
call xmlhttp component, but It's the same for any transformer, I
guess
Here is my code.
package myGenerators;
import org.apache.avalon.excalibur.pool.Poolable;
import org.apache.cocoon.components.parser.Parser;
import
On 04.03.2004 20:10, Stefano Mazzocchi wrote:
Just keep in mind that everytime you do code generation IDEs that
need to compile classes to operate (like Eclipse or Idea) choke big
time.
Haven't had this experience. All the time things got out-of-date I ran an
Ant script to exec xdoclet. Eclipse
Corin Moss wrote:
Hiya,
Someone may have gotten to this first - it means that the properties
file for the JCS config isn't in your classpath.
I thought I tried that. Must be because I running from within Eclipse.
It does not make much sense to me though. Why first do
JCS.setConfigFilename()
Hiya,
I agree with you there - this is the default behaviour of
setConfigFilename - it just wraps a properties reader (well, a method is
subsequently calls does), which of course requires the file to be in the
classpath. When I first implemented that bit I didn't realise that it
was a
Joerg Heinicke wrote:
We also had no problems with it. As Hamilton said you just must not
commit generated code, but I think that's obvious. Do you have something
else in mind? What does distributed workgroup change on the issue?
that there is more chance of people making mistakes ;-)
we *did*
On Thu, 04 Mar 2004 09:06:17 +
Upayavira [EMAIL PROTECTED] wrote:
Okay, Simon, sorry for my delay in replying.
Here's my idea of what I'd like to see.
Firstly, I'd ___love___ to see a really thin GUI, with no
editors (or a really cut down notepad style editor) living
within Cocoon
Unico Hommes wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip/
But then you have to change every component that currently iterates
over the parameters and every component has to filter.
We actually really introduced an incompatible feature and to be
honest, I don't even know where
Vadim Gritsenko dijo:
[EMAIL PROTECTED] wrote:
antonio 2004/03/03 23:01:56
Modified:lib jars.xml
Log:
Updated POI to 2.5-final-20040302
Is name of the JAR file coming from POI project? It's weird to see
poi-2.5-final-20040302 instead of poi-2.5 as for other projects.
Hey folks --
I just upgraded my web application from 2.1.3 to 2.1.4 and I am now
seeing some strange behavior from the woody template transformer. It
seems that elements in the xhtml namespace come out the other side of
the woody template transformer without their names! To reproduce this,
On 04.03.2004 08:53, [EMAIL PROTECTED] wrote:
antonio 2004/03/03 23:53:55
Modified:.build.bat
Added: .appendcp.bat
Log:
Don't copy endorsed jars to lib/tools
Cool, his avoids finally the useless copying of the XML jars into
tools/lib. Thanks, Antonio. I just
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=27456.
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=27456.
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=27457.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I did a little more poking around, and it turns out that even though the
woody template transformer mangles the xml document, the problem does
not appear unless you run the document through the identity xslt transform.
Simple example:
test.xml
html xmlns=http://www.w3.org/1999/xhtml;
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=27457.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
If I have a form which contains a repeater, example being the sample
form in the woody blocks, focus goes to the first submit button on the
form.
In the sample XMLBinding form, for instance, if I enter an email address
and then hit enter it will submit the Add Contact button. Adding a
On 04.03.2004 05:04, Antonio Gallardo wrote:
Joerg Heinicke dijo:
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
wb:unique-row
wb:unique-field id=myId1 path=myId1/
wb:unique-field id=myId2 path=myId2/
/wb:unique-row
wb:on-bind
wb:value id=myId1 path=myId1/
On 05.03.2004 01:54, Antonio Gallardo wrote:
[EMAIL PROTECTED] dijo:
joerg 2004/03/04 16:44:50
Modified:.build.bat build.sh
Log:
removed the output of the very temporary classpath
I think it is a good info for users. Often the problems are related to the
usage of any of
Hi Joerg:
If the problem is just to change a name:
from wb:unique-field to wb:value
Then, no problem from my side. If you agree, I will change the code and
this issue can be closed, right? :-D
Best Regards,
Antonio Gallardo.
On 05.03.2004 02:10, Antonio Gallardo wrote:
Hi Joerg:
If the problem is just to change a name:
from wb:unique-field to wb:value
Then, no problem from my side. If you agree, I will change the code and
this issue can be closed, right? :-D
No, please don't do another fast shot. I would like to
On 03.03.2004 22:20, J.Pietschmann wrote:
Joerg Heinicke wrote:
It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP
people must clarify if this made any sense or not. IIRC we had the
released Fop jar in our CVS and got complaints for problems with Batik
after Batik update.
Joerg,
Sorry for the delay in replying...
On 28.02.2004 19:18, Steve Schwarz wrote:
Thanks for the info.
I tried replacing the Cocoon jars: batik-all-1.5.jar fop-0.20.5.jar
with the FOP 0.20.5 jars (fop.jar batik.jar) in that case no SVG is
rendered at all because there is a problem with use
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=27456.
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=27302.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Title: Turning off default MRU store
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to try and turn off the default MRU store, in favour of the JCS based persistent store. I'd like to try some tests on performance without the default MRU - has anyone else tried
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=27254.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg,
Here's an example xml that produces the problems (svg:use url failure for
FOP versions of fop/batik jars and scaling problem for Cocoon versions of
fop/batik jars):
if you call it bar.xml:
?xml version=1.0 encoding=UTF-8?
fo:root xmlns:svg=http://www.w3.org/2000/svg;
Corin Moss dijo:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to try and
turn off the default MRU store, in favour of the JCS based persistent
store. I'd like to try some tests on performance without the default
MRU - has anyone else tried anything similar? I've
Corin Moss wrote:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to try and
turn off the default MRU store, in favour of the JCS based persistent
store. I'd like to try some tests on performance without the default
MRU - has anyone else tried anything similar? I've
On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote:
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
wb:unique-row
wb:value id=myId1 path=myId1/
wb:value id=myId2 path=myId2/
/wb:unique-row
wb:on-bind
wb:value id=field1 path=field1/
wb:value
Unico Hommes wrote:
Corin Moss wrote:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to try and
turn off the default MRU store, in favour of the JCS based persistent
store. I'd like to try some tests on performance without the default
MRU - has anyone else tried
---BeginMessage---
Hiya,
It does exactly that. The MRU store can be figured for max objects in the same way as
our current MRU. As far as differenciating what is stored in persistent as opposed to
transient, that could be done through configuration of different store regions. I'm
fairly
XDoclet is a good generator, but the license is wrong for Apache.
Using straight Introspection can and will expose things that you do not
wish to allow users to alter on the fly.
Unfortunately I'm completely snowed under until March 29th. After that
date I will get back to working on JMX for
Le Jeudi, 4 mars 2004, à 22:56 Europe/Zurich, Sylvain Wallez a écrit :
Although individual parameter location may be useful, the location
parameter I'm talking about is that of the statement. This makes me
think SitemapParameters with a getStatementLocation() is better
than
Sylvain Wallez wrote:
So here's a proposal (I should have thought about it way earlier...):
let's use a LocatedParameters, subclass of Parameters
with an additional getLocation() method. It has no impact
on components that iterate on parameters, and yet still
provide location whenever
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
So here's a proposal (I should have thought about it way
earlier...):
let's use a LocatedParameters, subclass of Parameters
with an additional getLocation() method. It has no impact on
components that iterate on parameters, and yet
Thor Heinrichs-Wolpert wrote:
Carsten, if your offering to answer questions on Avalon, that
would be way cool.
Sure. You know the rules: one beer for each answer :)
(PS: That's just a joke)
Carsten
Title: Message
Hi,
I am facing this
problem for a long time and is not able to solve it. When I aggregate a jsp file
within the map:aggregate, I can get the following
error:
org.apache.cocoon.ProcessingException: Failed to
execute pipeline.: org.apache.cocoon.ProcessingException:
82 matches
Mail list logo
