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=21107.
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=21107.
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=27013.
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=27013.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Folks,
please noone take this personal (reinhard,
please don't) but am I the only one that
thinks that this use of bugzilla is kinda
awkward?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25114
Having the Cocoon Forms overview in
bugzilla to gather the dependency list
is perfect IMHO.
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=25083.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Torsten:
I think it is a good place to have it. It allow us to remember that it was
discussed and someday it will be implemented?
If this is not going to be implemented, because lack of interest, then I
will agree to remove it. But in this case I think some people have
interest to implement
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=29381.
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=16545.
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=16545.
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=16545.
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=29864.
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=26725.
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=28650.
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=28650.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
On 5 Jul 2004, at 22:16, Gianugo Rabellino wrote:
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemapU
RI();
}
but being a freshman on Cocoon flow
On 6 Jul 2004, at 10:04, Andrew Savory wrote:
Hi,
On 5 Jul 2004, at 22:16, Gianugo Rabellino wrote:
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
Unico Hommes wrote:
Antonio Gallardo wrote:
Upayavira dijo:
Antonio Gallardo wrote:
Upayavira dijo:
Alan wrote:
I'm wondering if there is a way to cache JXTemplate, or any
Gianugo Rabellino wrote:
We had an interesting night here, dealing with a really nasty
flowscript issue
(http://marc.theaimsgroup.com/?t=10879848851r=1w=2). Thanks to
the precious help of Jerm, Andrew and Paul Russell, our small
hackaton seemed to be successful in at least nailing the
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=28056.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Bruno Dumon wrote:
On Sat, 2004-07-03 at 22:38, Sylvain Wallez wrote:
Joerg Heinicke wrote:
This thread on users list was about implementing the setValue() method
on the upload widget. The use case is - as the subject says - editing
existing list of uploads. The complete thread can be
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=28724.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote:
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap
UR I();
}
Aargh! You should absolutely
Unico Hommes wrote:
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
snip/
Oh but I think I see now. The cache-key and cache-validity objects
are associated with the compiled template object using template
properties. The compiled template
Carsten Ziegeler wrote:
Our request object is modelled after the request object of
the servlet spec. Now this approach is not bad, but Cocoon
has something which the servlet spec does not have: internal
requests. Unfortunately, our api does not take this into
account.
URIs
The request has
Gianugo Rabellino wrote:
On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote:
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap
UR I();
}
Aargh!
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used prefix everywhere else.
Ok, I like your suggestion more.
Attributes
--
We have a similar problem with attributes on
Gianugo Rabellino wrote:
On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote:
I changed that to
private String getSitemapPath() throws Exception {
return ObjectModelHelper.getRequest(
EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap
UR I();
}
Aargh!
On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote:
There is a solution, though: there's a different FlowIntepreter for
each Processor instance (they are SingleThreaded), and so each
interpreter instance could produce a unique identifier and use it as
the result of getSitemapPath (which
Unico Hommes wrote:
Unico Hommes wrote:
I am carrying this over to dev@ so other developers can comment.
Leszek Gawron wrote:
Unico Hommes wrote:
snip/
Oh but I think I see now. The cache-key and cache-validity objects
are associated with the compiled template object using template
properties.
Gianugo Rabellino wrote:
On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote:
There is a solution, though: there's a different FlowIntepreter
for each Processor instance (they are SingleThreaded), and so
each interpreter instance could produce a unique identifier and
use it as the result of
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used prefix everywhere else.
Ok, I like your suggestion more.
snip/
SNIP/
What about adding a list of
On 05.07.2004 15:03, Matthias Stöckel wrote:
Hi,
I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few
issues about JDK 1.3.1 compatibility.
- jakarta-bcel-20040329.jar, NoSuchMethodError if used with JavaFlow [1].
Are you sure it's the quoted StringBuffer problem? It might also
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used prefix everywhere else.
Ok, I like your suggestion more.
Cool.
snip/
I was recently looking at
Joerg Heinicke wrote:
On 04.07.2004 16:35, [EMAIL PROTECTED] wrote:
1.3 +7 -5
cocoon-2.1/src/blocks/forms/samples/messages/FormsMessages_zh_CN.xml
-?xml version=1.0 encoding=UTF-8?
+?xml version=1.0 encoding=UTF-8?
This is a correct change; file before change was not a valid
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=29935.
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=29935.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Big +1 , but what about naming it getSitemapPath() to mimic
HttpServletRequest.getServletPath()?
Hm, sounds better to me, but we have used prefix everywhere else.
Ok, I like your suggestion more.
snip/
SNIP/
What about
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=29381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
// this works
var formSubSurvey2= new Form( cocoon:/dynamicFormDefinition.do?id=1 );
form.showForm( form/subSurvey, { } );
if ( form.submitId == edit-group ) {
// and this does not (OOME)
var formSubSurvey2= new Form(cocoon:/dynamicFormDefinition.do?id=1);
}
--
Unico Hommes wrote:
Leszek Gawron wrote:
Unico Hommes wrote:
...
There is one other thing. The cache key that is returned by
JXTemplateGenerator should be the src + jx:cache-key attribute
value. Since the jx:cache-key is only a hash of the objects that are
used in the template. These could, in
Sylvain Wallez wrote:
Gianugo Rabellino wrote:
On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote:
There is a solution, though: there's a different FlowIntepreter
for each Processor instance (they are SingleThreaded), and so
each interpreter instance could produce a unique identifier and
use
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable, Recyclable) or by
Joerg Heinicke dijo:
Yes, we decided to beware 1.3 compatibility as long as we need no
feature of 1.4. The above issues don't make it necessary to switch to 1.4.
Each day is harder and harder to find the libs compiled for 1.3. I found
my self being compiling a lot of jars before commiting an
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=29381.
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=29924.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I was told that this might be a bug in cocoon.
Currently using cocoon 2.1.3
I have in cocoon.xconf:
component-instance
class=org.apache.cocoon.components.modules.input.XMLFileModule
logger=core.modules.xml name=joose
file src=cocoon:/internal/config.xml reloadable=true
cacheable=false
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=20381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
On 05.07.2004 15:03, Matthias Stöckel wrote:
Hi,
I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few
issues about JDK 1.3.1 compatibility.
- jakarta-bcel-20040329.jar, NoSuchMethodError if used with JavaFlow
[1].
Are you sure it's the quoted
Joose Vettenranta wrote:
Hi,
I was told that this might be a bug in cocoon.
Currently using cocoon 2.1.3
I have in cocoon.xconf:
component-instance
class=org.apache.cocoon.components.modules.input.XMLFileModule
logger=core.modules.xml name=joose
file src=cocoon:/internal/config.xml
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Gianugo Rabellino wrote:
On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote:
There is a solution, though: there's a different FlowIntepreter
for each Processor instance (they are SingleThreaded), and so
each interpreter instance could produce a
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable,
Antonio Gallardo wrote:
Joerg Heinicke dijo:
Yes, we decided to beware 1.3 compatibility as long as we need no
feature of 1.4. The above issues don't make it necessary to switch to 1.4.
Each day is harder and harder to find the libs compiled for 1.3. I found
my self being compiling a lot
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
JavaScriptInterpreter should have an id attribute intialized once,
whose value is used instead of getSitemapPath(), e.g.
private String interpreterID = IDGenerator.getNewID();
System.identityHashCode(this) is much simpler than
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned
up or not. This could be done by either testing for the usual
suspects
Torsten Curdt wrote:
Folks,
please noone take this personal (reinhard,
please don't)
no problem. I'm always interested in other opinions.
but am I the only one that
thinks that this use of bugzilla is kinda
awkward?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25114
Having the Cocoon Forms
Sylvain == Sylvain Wallez [EMAIL PROTECTED] writes:
I think those listeners are not only for flowscript, but more
generic approach. Btw, sendPageAndWait also has a provision for
clean up function. Problem is it does not work each time [1].
Sylvain Yep. We could reimplement
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=20381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Colin Paul Adams [EMAIL PROTECTED] writes:
snipflow listener discussion,/snip
I've just read this thread, because I have been trying to
work out how to implement pessimistic locking within cocoon.
A problem is how to close a database transaction if the user
simply walks away from the
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
from Avalon (Disposable,
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned up
or not. This could be done by either testing for the usual suspects
after Betrand's great presentation at the GetTogether last year we
agreed that we try Bugzilla. At this time we had a list in our Wiki of
all requirements which are prerequisits for a stable CocoonForms block
and many people thought that this wasn't the best way.
And I am sure fine with that!
Peter == Hunsberger, Peter [EMAIL PROTECTED] writes:
Peter Colin Paul Adams [EMAIL PROTECTED] writes:
Peter snipflow listener discussion,/snip
I've just read this thread, because I have been trying to work
out how to implement pessimistic locking within cocoon. A
problem
Colin Paul Adams [EMAIL PROTECTED] writes:
Peter == Hunsberger, Peter
[EMAIL PROTECTED] writes:
Peter Colin Paul Adams [EMAIL PROTECTED] writes:
Peter snipflow listener discussion,/snip
I've just read this thread, because I have been trying to work
out how to
Colin == Colin Paul Adams [EMAIL PROTECTED] writes:
Peter Maybe I'm missing something, but why aren't you setting
Peter your database transaction timeout limit to something just a
Peter bit larger than the session timeout?
Colin Well, I guess this is fine for a database server
Colin Paul Adams [EMAIL PROTECTED] writes:
In fact, checking the documentation for postgresql, it
doesn't have transaction timeout, only statement timeout,
which certainly isn't adequate.
I've never had to worry about it at the DB level, we use JBoss and
manage it at the container level.
Peter == Hunsberger, Peter [EMAIL PROTECTED] writes:
Peter If all you've got is statement timeout a wrapper around the
Peter execute/executeQuery should work?
I don't see how it can possibly work.
The scenario:
Read data, starting a transaction and bind to a CForms.
Wait for the user
Peter == Hunsberger, Peter [EMAIL PROTECTED] writes:
Peter I believe you should be able define the timeout at the DB
Peter (JDBC/ODBC?) connection pool level when you define the
Peter connection for the application, not?
I don't know. Where would this be done? Within cocoon?
--
Colin Paul Adams [EMAIL PROTECTED] writes:
Peter == Hunsberger, Peter
[EMAIL PROTECTED] writes:
Peter If all you've got is statement timeout a wrapper around the
Peter execute/executeQuery should work?
I don't see how it can possibly work.
The scenario:
Read data, starting
Colin Paul Adams [EMAIL PROTECTED] asks:
Peter == Hunsberger, Peter
[EMAIL PROTECTED] writes:
Peter I believe you should be able define the timeout at the DB
Peter (JDBC/ODBC?) connection pool level when you define the
Peter connection for the application, not?
I don't
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
Now, the basic mechanism for this could be to scan all attribute
values of the request and find out if the value should be cleaned
up or not. This could be done by either testing for
Hi all,
I have successfully deployed Cocoon JSR-168 Portlet into Cocoon Portal.
Now, you can deploy your portlets implemented using Cocoon into Cocoon's
own portal.
There is a very simple demo of the Cocoon JSR-168 portlet included, just
go to the JSR168 tab in the portal block demo. The only
I was going to suggest HttpSessionBindingListener as well. In fact, it is
kind of pointless for Cocoon to implement a SessionListener since it would
have to do it through a SessionBindingListener anyway.
Ralph
Sylvain Wallez said:
Hunsberger, Peter wrote:
Or you can also add store in a
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=29381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 6 Jul 2004, at 17:27, Vadim Gritsenko wrote:
Antonio Gallardo wrote:
Joerg Heinicke dijo:
Yes, we decided to beware 1.3 compatibility as long as we need no
feature of 1.4. The above issues don't make it necessary to switch
to 1.4.
Each day is harder and harder to find the libs compiled for
75 matches
Mail list logo
