Corin Moss dijo:
Hiya,
JCS certainly has an implementation of a r/w lock:
http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/utils/locking/
ReadWriteLock.html
While reviewing the code at line 111 is interesting to me why wait full 2
seconds on it. It is a lot of time!
Based on my
Bruno Dumon wrote:
On Sun, 2004-03-07 at 17:43, Joerg Heinicke wrote:
On 06.03.2004 19:09, Reinhard Pötz wrote:
The first part is done - which means:
- renaming of all Java classes
- reflect changes within Flowscripts
- first run on updating all samples
open
- Stylesheet for namespace
Antonio Gallardo wrote:
This mean another official forking of the Rhino engine. That also mean
users of BEA and IBM AS will have 2 flowscript engine there, right? The
current deployed with org.mozilla.* and our one org.cocoondev.*
This can be easily traduced in more memory usage, etc. Is this
Antonio Gallardo wrote:
Christopher Oliver dijo:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev. The Rhino codebase used in
Reinhard:
I understand the POV. On the one hand the need to allow BEA and IBM use
Flow. I think it is great! And I am +1 here.
On the other side, I don't like the forking idea (as I don't liked it in
jisp). I know we currently use a forked version, but giving it a
official status is what I don't
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=25934.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steven Noels dijo:
On 08 Mar 2004, at 03:59, Christopher Oliver wrote:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev.
Who
Antonio Gallardo wrote:
Reinhard:
I understand the POV. On the one hand the need to allow BEA and IBM use
Flow. I think it is great! And I am +1 here.
On the other side, I don't like the forking idea (as I don't liked it in
jisp). I know we currently use a forked version, but giving it a
Antonio Gallardo wrote:
Steven Noels dijo:
On 08 Mar 2004, at 03:59, Christopher Oliver wrote:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from
Carsten Ziegeler wrote:
Corin Moss wrote:
JCS certainly has an implementation of a r/w lock:
http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/util
s/locking/
ReadWriteLock.html
The indexed disk cache certainly uses it, as I suspect does
any other cache which needs such a thing. So I
Ugo Cei dijo:
Antonio Gallardo wrote:
This mean another official forking of the Rhino engine. That also mean
users of BEA and IBM AS will have 2 flowscript engine there, right? The
current deployed with org.mozilla.* and our one org.cocoondev.*
This can be easily traduced in more memory
Gianugo Rabellino wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
workflow-manager
state name=tobeprocessed class=TobeprocessedState
entering-action class=TobeprocessedAction/
/state
state name=beingprocessed class=BeingprocessedState
entering-action class=BeingprocessedAction/
Hi:
Is posible to replace tool/src/anttask/ManifestToolTask.java with:
http://ant.apache.org/manual/CoreTasks/manifest.html
Are we using ManifestToolTask at all? If so, why? can we change the
implementation to use manifest instead?
Best Regards,
Antonio Gallardo
On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:
IIRC the argumentation was that Cocoon is about web publishing and web
applications and not about programming language interpreters. So it
should find a different place.
Exactly.
And a forked version of a well-known open source project of a
Am Mo, den 08.03.2004 schrieb Steven Noels um 10:11:
On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:
IIRC the argumentation was that Cocoon is about web publishing and web
applications and not about programming language interpreters. So it
should find a different place.
Exactly.
Stephan Michels wrote:
Am Mo, den 08.03.2004 schrieb Steven Noels um 10:11:
On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:
IIRC the argumentation was that Cocoon is about web publishing and web
applications and not about programming language interpreters. So it
should find a different
Steven Noels wrote:
On 08 Mar 2004, at 03:59, Christopher Oliver wrote:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev.
Who
On Sun, 07 Mar 2004 21:47:26 +0100, Gianugo Rabellino [EMAIL PROTECTED]
wrote:
Guido Casper wrote:
Gianugo Rabellino wrote:
For one, this might buy usage of some well-established worflow
description languages, such as XPDL or BPEL: this would mean, in turn,
being able to use existing tools to
Johan Stuyts wrote:
On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our
On Mon, 08 Mar 2004 11:41:12 +0100, Unico Hommes [EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
On Fri, 05 Mar 2004 17:18:53 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we
While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:
map:redirect-to uri=cocoon://something/
than this is an internal pipeline call (and not a new http request).
This has
Carsten Ziegeler wrote:
While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:
map:redirect-to uri=cocoon://something/
than this is an internal pipeline call (and not a new
Unico Hommes wrote:
I am just thinking whether it'd be worth a separate protocol
something like forward://something ?
Yes, I thought of this as well. Unfortunately we have to many hardcoded
places, where against the protocol name cocoon: is tested. So if
we provide a new protocol we have to
Carsten Ziegeler wrote:
Unico Hommes wrote:
I am just thinking whether it'd be worth a separate protocol
something like forward://something ?
Yes, I thought of this as well. Unfortunately we have to many hardcoded
places, where against the protocol name cocoon: is tested. So if
we
On 4 Mar 2004, at 11:26, Sylvain Wallez wrote:
Hi all,
This is a bit OT, but I encountered some problems with file uploads on
MacOSX, using the woody upload sample
(http://localhost:/samples/woody/upload):
- with Safari, no upload happens at all! I checked the incoming
stream, and the
Antonio Gallardo wrote:
Hi:
If we will have 1.4 as a minimum requirement for Cocoon 2.2, we can take
advantage of parallel building in Cocoon:
http://ant.apache.org/manual/CoreTasks/parallel.html
I wonder how much we can reduce the building time by compiling blocks in
parallel thread.
I
On 06 Mar 2004, at 23:40, Upayavira wrote:
Please let me know your comments, publically or privately, so that we
can get this site working really well.
Spaces in between [] (JSPWiki) should be collapsed, I think: [Steven
Noels] - StevenNoels
We should also cater for [SN|Steven Noels] -
Unico Hommes wrote:
Carsten Ziegeler wrote:
Unico Hommes wrote:
I am just thinking whether it'd be worth a separate
protocol something
like forward://something ?
Yes, I thought of this as well. Unfortunately we have to
many hardcoded
places, where against 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=27432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes wrote:
Antonio Gallardo wrote:
Hi:
If we will have 1.4 as a minimum requirement for Cocoon 2.2, we can take
advantage of parallel building in Cocoon:
http://ant.apache.org/manual/CoreTasks/parallel.html
I wonder how much we can reduce the building time by compiling blocks in
I don't really want to delve too deeply into this (the mail would become
very long ;-) but...
the core problem IMO is the current concept(s) of the sitemap; I had that
feeling already when starting with Cocoon, hearing about the 'sitemap' and
then looking at it and being confused.
and when
As the FormValidatorAction is not cool fancy and new it still intruduces some
interesting functionality that does not exist in flow. Suppose you do not use
CForms in all your application views. So you have plain html with links that
will trigger some flow function:
Christopher Oliver wrote:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev. The Rhino codebase used in Cocoon is currently hosted
Antonio Gallardo wrote:
Hi:
Reading the main LICENSE in Cocoon, seems like we forgot to fill this line:
Copyright [] [name of copyright owner]
No. This is intentional. Please re-read paragraph above this line, and
then re-read chapter 1, definition of Work.
Vadim
Antonio Gallardo wrote:
Hi:
Is posible to replace tool/src/anttask/ManifestToolTask.java with:
http://ant.apache.org/manual/CoreTasks/manifest.html
Are we using ManifestToolTask at all? If so, why? can we change the
implementation to use manifest instead?
Take a look at what it does (see
On 08 Mar 2004, at 11:16, Sylvain Wallez wrote:
Very good point. It cannot be the ASF, and cocoondev.org isn't a legal
entity that can hold a copyright. Considering that rhino+cont's single
author is Chris, he could be the copyright holder, but community-wise
this doesn't sound good.
And in
Carsten Ziegeler wrote:
While using internal cocoon redirects, I found out that there are
potential problems with error handling (it might be that we have
discusses this already...).
Now, if you do a:
map:redirect-to uri=cocoon://something/
than this is an internal pipeline call (and not a new
On Mon, Mar 08, 2004 at 03:32:44PM +0100, Steven Noels wrote:
Maybe we could rename it into Cocoon Scripting Engine while we are at
it - as this seems to be a common usage pattern. ;-)
Now you made me LOL :)
--Tim Larson
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Sorry, what is technically nearly impossible??
Without changing the interfaces and without having a clean separation of concerns, it's not possible. Of course if we change some core interfaces, the treeprocessor and the pipeline
Sylvain Wallez wrote:
Ah yes, I understand the technically nearly impossible now:
- pipeline building is always under control of the
treeprocessor. So in that phase, this is possible.
Yes.
- for external requests, pipeling processing occurs within
the treeprocessor (in the node that
Is it possible to specify the error handling as an attribute of
map:redirect-to instead of a parameter of the uri? It feels awkward to have
to do it that way. Obviously, if it needed to tacked on to the uri
internally so it could be picked up later in the pipeline processing that
could be done,
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Is it possible to specify the error handling as an attribute
of map:redirect-to instead of a parameter of the uri? It
feels awkward to have to do it that way. Obviously, if it
needed to tacked on to the uri internally so it could be
picked
I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937
thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
Marco Rolappe wrote:
I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937
thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
Hmm, more bad news about JCS. It's
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=27518.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Guido Casper [EMAIL PROTECTED] writes:
Continuations within a webapps are better than a FSMs because
the FSM approach is just a workaround for the lack of a
single-threaded view of my webapp and continuations brought
back that view to me. However for potentially everlasting
conditional
Marco Rolappe wrote:
I stumbled over the following thread in the hibernate forum about JCS
problems:
http://forum.hibernate.org/viewtopic.php?t=924937
thought it might be useful to know before going JCS. there's also an
alternative (EHCache) mentioned.
I've been using EHCache in production with
Stefano Mazzocchi [EMAIL PROTECTED] writes:
snip/
In that situation, asking a user to write a new version of
a program
for
that specific need doesn't seem a good solution to me ;-)
Wait a second: to you think that guy would be more confortable in
writing a FSM code?
Let's
Johan Stuyts wrote:
Using the GoF State pattern works
great for simple state machines and I use it a lot. But the pattern does
not talk about nested and/or parallel states, which become
incomprehensible when coded in Java; the state machine logic gets
intermixed with the document logic.
Johan,
...
1. test2.jsp: Call to
portalContext.getSupportedWindowStates() returns null.
I fixed this (hopefully) yesterday morning in the CVS.
Haven't got chance to test it again. After I updated my whole cocoon-distribution from
CVS and build clean webapplication only with portal-block
On 08 Mar 2004, at 06:23, Ralph Goers wrote:
I would request that you poll your users. I am not in favor of this.
I don't think there would be any reason to remove these lightweight
form handling components from Cocoon. You should expect however that
the majority of development effort goes
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling tools for
building work flow, the internal implementation should be completely
transparent; the first time I wrote GUI modeling tools for work flow was
13 years ago (as a subcontractor for one of the major work
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
transparent; the first time I wrote GUI modeling tools for
work flow
was 13
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=26011.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hello Carsten,
you removed jstyle.jar some days ago during updating the licenses. Was
the removal by intention? Cocoon 2.2 does no longer compile
(JStyleFormatter.java). Has this styling ever been in use?
Joerg
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
transparent; the first time I wrote GUI modeling tools for
On 08.03.2004 03:59, Christopher Oliver wrote:
In order to allow the use of Flowscript on the BEA Weblogic and IBM
Websphere application servers (and possibly in other environments) I
propose that we rename the Rhino packages from org.mozilla to
org.cocoondev. The Rhino codebase used in Cocoon
On 08.03.2004 20:09, Steven Noels wrote:
I would request that you poll your users. I am not in favor of this.
I don't think there would be any reason to remove these lightweight form
handling components from Cocoon. You should expect however that the
majority of development effort goes into
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=26086.
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=26445.
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=26456.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes wrote:
Christian Haul wrote:
Unico Hommes wrote:
However, I'm not quite sure if this is the way to go. I'm currently
thinking of intercepting and wrapping sources at the selector level.
With the current setup, we need to add the configuration to the URL
in all places it is used. By
Pier Fumagalli [EMAIL PROTECTED] writes:
snip/
The way the JVM classloading mechanism is designed (well, the code
verifier actually) is that you cannot have two classes with
the same
name and package in the same classloading hierarchy.
So, for example, suppose you have the following
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=26851.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Unico Hommes unico at hippo.nl writes:
Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
keeps saying:
ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
Exception
java.io.IOException: Bad
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=26963.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
Unico Hommes unico at hippo.nl writes:
Hmm, but it seems Jisp is doing the bad thing again. Upon storage it
keeps saying:
ERROR (2004-02-29) 14:23.34:294 [core.store.persistent]
(Unknown-URI) Unknown-thread/AbstractJispFilesystemStore: store(..):
Exception
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=26851.
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=27484.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I agree that this is bad news.
Before a decision is made one way or another, it might be a good idea to
agree on minimal functionality required of a store. I'm not overly in
favour of a true light-weight cache like EHCache being the only
supported caching mechanism. In my usage of JCS I
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=26456.
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=26851.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 08.03.2004 22:23, [EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=26456
First Xindice DB is created in current directory (instead of WEB-INF?)
--- Additional Comments From [EMAIL PROTECTED] 2004-03-08 21:23 ---
Umm, I guess I underestimated my workload, so
On 08.03.2004 22:36, [EMAIL PROTECTED] wrote:
unico 2004/03/08 13:36:26
Added: src/blocks/scratchpad/lib ehcache-0.7.jar
src/blocks/scratchpad/java/org/apache/cocoon/components/store
EHStore.java
legal
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Guido Casper [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
For the end user I believe you always have to have modeling
tools for
building work flow, the internal implementation should be
completely
Antonio Gallardo wrote:
Sorry, but, I am still -0. :-(
We are all open to better solutions, Antonio, but I personally see none.
It's not easy matter and forking is a painful thing, but we *must* do
something.
If you have a better idea, I'm all ears. Keep in mind that along with
the idea
Upayavira wrote:
Antonio Gallardo wrote:
Upayavira dijo:
I've been working on converting the JSPWiki Cocoon wiki to MoinMoin
wiki. This will enable Cocoon to make use of Apache's Wiki farm.
Thanks fro your effort.
I already noted many pages are Orphaned:
Steven Noels wrote:
On 08 Mar 2004, at 09:39, Reinhard Pötz wrote:
IIRC the argumentation was that Cocoon is about web publishing and web
applications and not about programming language interpreters. So it
should find a different place.
Exactly.
And a forked version of a well-known open
Corin Moss wrote:
Would it be worth polling the users and dev lists to get something of a
wish-list for store functionality?
why don't we go back and see what is the problem we are trying so solve
instead of branching off like crazy?
we must store lots of objects persistently and retrieve them
(partly in reply to
http://thread.gmane.org/gmane.comp.mozilla.devel.jseng/3038)
Dear all, more specifically Rhino devs,
the issue with Cocoon's Rhino fork seems to be appearing with
increasing rate on both the Rhino and Cocoon mailing lists. While the
discussion underneath remains
On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:
unless donated by the well-known friendly-neightbor-organization
directly, that is.
I took the plunge and started talking. See my other mail.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source
Hiya,
I don't think that anyone disagrees that the issue of utmost importance
for the Store is fast and simple. The work done to date on JCS, and now
EHCache highlights that there are some fairly well developed caching
systems out there. Most of them fulfil the first requirement, some of
them
If I understand the issue correctly... We have purchased Tangosol Coherence
so if there is a way that whatever Cocoon uses is pluggable enough that a
third party product could be used instead of a light-weight solution (i.e.
to provide clustering support) that would be great. I believe Coherence
Defect:
The following defect occurs ONLY on the MS windows platform,
it does NOT occur on the linux platform.
Both platforms were setup with tomcat 4.1.29, and cocoon 2.1.4.
On the windows platorm, a woody form will lose it's data when
the enctype=multipart/form-data is specified in the form
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=27020.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 08.03.2004 22:30, Alex Romayev wrote:
Hi,
Paginator transformer seems to be broken in CVS. The
sample produces: java.lang.ClassCastException.
Sorry, but I can not confirm it as it works for me.
Joerg
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=27147.
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=25113.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hiya,
This might be unrelated to the Paginator itself.
I noticed last night that when I used the JCSTransientStore I got a
class cast exception when trying to write to the transient cache. I
haven't had a chance to look at this more - but this might be it.
Although I'd imagine that it would
On 09.03.2004 00:16, Corin Moss wrote:
As I said before, the advantage of JCS is that it provides an interface
to many different store types - which greatly enhances the functionality
of Cocoon. I don't think there's much point in developing yet another
cache library when there are lots out
If JCS is just an abstraction layer I wonder why it has the problems
identified with it? I would expect that it wouldn't be difficult to plug in
EHCache to JCS if that is the case.
Ralph
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004
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=27260.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Corin Moss wrote:
Would it be worth polling the users and dev lists to get something of a
wish-list for store functionality?
why don't we go back and see what is the problem we are trying so solve
instead of branching off like crazy?
Admittedly, I was a little bit
Joerg Heinicke wrote:
On 09.03.2004 00:16, Corin Moss wrote:
As I said before, the advantage of JCS is that it provides an interface
to many different store types - which greatly enhances the functionality
of Cocoon. I don't think there's much point in developing yet another
cache library
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=27275.
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=26445.
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=27275.
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=27275.
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=27301.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Steven Noels wrote:
On 08 Mar 2004, at 23:09, Stefano Mazzocchi wrote:
unless donated by the well-known friendly-neightbor-organization
directly, that is.
I took the plunge and started talking. See my other mail.
Thanks for doing this Steven, it is truely appreciated from my part.
--
1 - 100 of 111 matches
Mail list logo
