Le 28 sept. 04, à 07:54, Stefano Mazzocchi a écrit :
...Also, the above seems to imply that you are writing your own
generators? or are you using XSP or what?
Yes, XSP all the way through...just kidding. It's MySQL, OJB, java
code, Flowscript, XSLT, map:aggregate, CInclude and more XSLT, in
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 27 Sep 2004, at 21:06, Vadim Gritsenko wrote:
What about using a similar approach to generate the cache? I'll try
to set up a test environment and to give it a shot if you have
nothing against it!
Do you refer to the
On 27 Sep 2004, at 23:43, Conal Tuohy wrote:
Pier Fumagalli wrote:
I was thinking about one thing... The one thing that troubles
us is the
request. That introduce a degree of variability that (i
don't know to
what degree), might be counter-productive to analyze and cache...
What about if we were
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
For somehow who maintained the previous Wiki for two years, and
reluctantly gave up after the daily reboots of JSPWiki became
Yes, it can be removed - I forgot about it :(
BTW, thanks for fixing my changes :)
Carsten
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Monday, September 27, 2004 10:35 PM
To: Cocoon Developers
Subject: Remove
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=31407.
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=31407.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Pier Fumagalli wrote:
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
Then we could re-create the request by something like:
incl:include src=proto://whatever
incl:param name=parameterNamevalue/incl:param
/incl:include
Well, if the only thing which troubles you is
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 27 Sep 2004, at 23:49, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
Then we could re-create the request by something like:
incl:include src=proto://whatever
incl:param name=parameterNamevalue/incl:param
/incl:include
On 28 Sep 2004, at 14:54, Pier Fumagalli wrote:
+// TODO: remove this debugging code!
+System.err.println(Including \ + encodedSource
+ \ from \
+ + source.getURI() + \ (
+ +
SourceForge.net wrote:
Project: ehcache (ehcache)
Package: ehcache
Date : 2004-09-28 07:03
Project ehcache ('ehcache') has released the new version of package 'ehcache'.
You can download it from SourceForge.net by following this link:
On 28 Sep 2004, at 15:07, [EMAIL PROTECTED] wrote:
Log:
update ehcache to version 1.0
Woohooo! :-P
Pier
smime.p7s
Description: S/MIME cryptographic signature
[EMAIL PROTECTED] wrote:
- !-- Experimental EHCache Store implementation --
+ !-- EHCache Store implementation --
Does it implement free() now?
/* (non-Javadoc)
* @see org.apache.excalibur.store.Store#free()
*/
public void free() {
// FIXME - we have to implement this!
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
i:parameter name=namevalue/i:parameter
Done, I'm posting the patch here before applying just to triple-check
I'm not f***ing up the whole thing. I mean, it works for me, but do a
quick
Unico Hommes wrote:
SourceForge.net wrote:
Project ehcache ('ehcache') has released the new version of package
'ehcache'.
I believe this was to be our cue for moving ehcache based store to the
core and making it our default right? I have just updated our ehcache to
the new release version but
On 28 Sep 2004, at 18:13, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
i:parameter name=namevalue/i:parameter
Done, I'm posting the patch here before applying just to triple-check
I'm not f***ing up the whole thing.
Vadim Gritsenko wrote:
Unico Hommes wrote:
SourceForge.net wrote:
Project ehcache ('ehcache') has released the new version of
package 'ehcache'.
I believe this was to be our cue for moving ehcache based store to
the core and making it our default right? I have just updated our
ehcache to the
Unico Hommes wrote:
Vadim Gritsenko wrote:
Unico Hommes wrote:
There still remains one FIXME in the EHCache store implementation
though. Method free() hasn't been implemented. AFAIK this one is
called by the StoreJanitor to do its work. However, although it works
a little different from ours,
Pier Fumagalli wrote:
On 28 Sep 2004, at 18:13, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 28 Sep 2004, at 12:00, Vadim Gritsenko wrote:
Go ahead, add parameters.
...
i:parameter name=namevalue/i:parameter
Done, I'm posting the patch here before applying just to triple-check
I'm not
On 28 Sep 2004, at 19:10, Vadim Gritsenko wrote:
Ok, like Hashtable usage:
+this.x_parameters = new Hashtable();
Instead of HashMap (with default map size):
+this.x_parameters = new HashMap(3);
FUDGE! :-) I blame that on Eclipse's auto-completion! ;-P
Or, like doing:
+this.x_source =
http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html
Pier
smime.p7s
Description: S/MIME cryptographic signature
Steven Noels wrote:
On 28 Sep 2004, at 10:39, Pier Fumagalli wrote:
Thanks, that I didn't know... Since the WIKI moved off to that
MoinMoin crap, I seriously tend to ignore it a lot more...
For somehow who maintained the previous Wiki for two years, and
reluctantly gave up after the daily
Pier Fumagalli wrote:
http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html
Pier
wow, what do you think it would take to create a CocoonServletNG?
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
On Sep 28, 2004, at 7:27 PM, Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html
Pier
wow, what do you think it would take to create a CocoonServletNG?
not too much, since we're already event based. maybe treat each
pipeline component
Carsten Ziegeler wrote:
Yes, it can be removed - I forgot about it :(
Done. Can you check this part though (that I had not screwed it up ;-)
@@ -796,7 +769,7 @@
if (outputStream == null) {
outputStream = environment.getOutputStream(0);
peter royal wrote:
On Sep 28, 2004, at 7:27 PM, Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
http://www.mortbay.com/MB/log/gregw/?permalink=servletNG.html
Pier
wow, what do you think it would take to create a CocoonServletNG?
not too much, since we're already event based. maybe treat each
26 matches
Mail list logo
