Replacement for hashcode() in CacheKeys...

[Antonio Gallardo]

Hi:

Looking inside commons-collections I found this class:

org.apache.commons.collections.keyvalue.MultiKey

I wonder if it can help in:

o.a.c.cache.ComponentCacheKey and
o.a.c.cache.PipelineCacheKey

inside the code of both hashcode() there is this comment:

// FIXME - this is not very safe

Best Regards,

Antonio Gallardo.

Re: JCS Based Cache

[Bertrand Delacretaz]

Le Mardi, 2 mars 2004, à 08:59 Europe/Zurich, Corin Moss a écrit :

...JCS does have its own R/W lock of course - but I'd love not to have 
to change too many classes ;)
I have no idea how the current locks work, but in this case the on-disk 
Store is going to be private to a single Cocoon instance, right?

If so, simple object-based in-memory locks would do - but maybe JCS or 
the current Store already work this way?

-Bertrand

AW: JCS Based Cache

[Marco Rolappe]

hi corin,

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Corin Moss
> Gesendet: Dienstag, 2. März 2004 08:59
> An: [EMAIL PROTECTED]
> Betreff: RE: JCS Based Cache
>
>
>
> You have a good point there - I'm simply going to have to replace
> the DefaultPersistentStore at my end (for testing only of course ;)
>
> One thing that has occurred to me whilst hammering the JISP based
> store, and looking at the code in a bit more depth, is that all
> of the perceived problems come as a result of the incredibly high
> iowait generated whilst accessing the store (mostly while writing
> I think.)  I notice that the AbstractReadWriteStore within the
> Excalibur components uses FIFOReadWriteLock as the lock - has
> anyone got much experience with this?  If there's a bug in there,
> it's possible that it's not relinquishing locks properly - which
> would most likely manifest in very high iowait (I theorise ;) I
> know that there are known issues with our version of JISP, but
> I'd like to be reassured first-hand that the read/write lock
> implementation we're currently using is totally robust.

I think the slow part was more due to JISP serializing out the index
(slooow) on each
writing access (remove, store, etc.).

unrelinquished locks would probably have manifested themselves in other ways
(e.g. complete lockup), but I might be wrong

RE: JCS Based Cache

[Corin Moss]

Yeah, they do - I don't see any point in changing them.  My question was really more 
about whether we're sure the current locks are problem free.  I see no reason to 
suspect otherwise, but I thought the question should be posed.  The lock used is:

EDU.oswego.cs.dl.util.concurrent.FIFOReadWriteLock

>From what I can tell it looks to be a very solid implementation.

I'll proceed without worrying about it at this point I think :)

Corin

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 2 March 2004 9:21 p.m.
To: [EMAIL PROTECTED]
Subject: Re: JCS Based Cache


Le Mardi, 2 mars 2004, à 08:59 Europe/Zurich, Corin Moss a écrit :

> ...JCS does have its own R/W lock of course - but I'd love not to have
> to change too many classes ;)

I have no idea how the current locks work, but in this case the on-disk
Store is going to be private to a single Cocoon instance, right?

If so, simple object-based in-memory locks would do - but maybe JCS or
the current Store already work this way?

-Bertrand



CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

RE: JCS Based Cache

[Corin Moss]

Hiya :)

I don't think you're wrong at all - I totally agree with you.  The interesting thing 
is that total lockup is what I experience at times :) iowaits approaching 99.9% when 
we do really heavy load testing (or sometimes even under particularly heavy "normal" 
usage.) 

On the bright side, JCS has this very interesting implementation:

http://jakarta.apache.org/turbine/jcs/IndexedDiskAuxCache.html

My initial concern was persistence, but given a clean shutdown the indices are written 
to disk :)

I think I'm becoming a bit of a JCS zealot - better be careful!! :)

-Original Message-
From: Marco Rolappe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 2 March 2004 9:24 p.m.
To: [EMAIL PROTECTED]
Subject: AW: JCS Based Cache


hi corin,

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Corin Moss
> Gesendet: Dienstag, 2. März 2004 08:59
> An: [EMAIL PROTECTED]
> Betreff: RE: JCS Based Cache
>
>
>
> You have a good point there - I'm simply going to have to replace the
> DefaultPersistentStore at my end (for testing only of course ;)
>
> One thing that has occurred to me whilst hammering the JISP based
> store, and looking at the code in a bit more depth, is that all of the
> perceived problems come as a result of the incredibly high iowait
> generated whilst accessing the store (mostly while writing I think.) 
> I notice that the AbstractReadWriteStore within the Excalibur
> components uses FIFOReadWriteLock as the lock - has anyone got much
> experience with this?  If there's a bug in there, it's possible that
> it's not relinquishing locks properly - which would most likely
> manifest in very high iowait (I theorise ;) I know that there are
> known issues with our version of JISP, but I'd like to be reassured
> first-hand that the read/write lock implementation we're currently
> using is totally robust.

I think the slow part was more due to JISP serializing out the index
(slooow) on each
writing access (remove, store, etc.).

unrelinquished locks would probably have manifested themselves in other ways (e.g. 
complete lockup), but I might be wrong




CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Stream vs Mapped IO (was Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2)

[Jorg Heymans]

Has anyone else read Bruce Eckel's "Thinking in Java" ?

 (chapter 12)
Although the performance of “old” stream I/O has been improved by 
implementing it with nio, mapped file access tends to be dramatically 
faster.


So by switching to 1.4 and *not* using NIO you're likely to get a speed 
bump already.

However switching to mapped file access (as was suggested before using 
memory mapped files) from traditional stream IO would gain the most 
significant increase.


Stream Write: 1719
Mapped Write: 359
Stream Read: 750
Mapped Read: 125
Stream Read/Write: 5188
Mapped Read/Write: 16

I am getting similar results over various runs. The test program is 
attached (needs the test harness classes to run, but you can see what 
he's doing)

The third edition including code samples is freely available from 
http://mindview.net/Books/DownloadSites

I hope this helps making the decision 1.4 vs 1.3. I also started a poll 
on the userlist to get a feeling of what the installed userbase is using 
at the moment. I'll gather some stats and report back.

Regards
Jorg
Antonio Gallardo wrote:

Hi:

Many was talked about this topic. I think it not need a large explanation:

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.
Do you agree with JSDK 1.4 as the lower Java version supported in Cocoon 2.2?

Here is my +1

Best Regards,

Antonio Gallardo

//: c12:MappedIO.java
// {Clean: temp.tmp}
// From 'Thinking in Java, 3rd ed.' (c) Bruce Eckel 2002
// www.BruceEckel.com. See copyright notice in CopyRight.txt.
import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class MappedIO {
  private static int numOfInts = 400;
  private static int numOfUbuffInts = 20;
  private abstract static class Tester {
private String name;
public Tester(String name) { this.name = name; }
public long runTest() {
  System.out.print(name + ": ");
  try {
long startTime = System.currentTimeMillis();
test();
long endTime = System.currentTimeMillis();
return (endTime - startTime);
  } catch (IOException e) {
throw new RuntimeException(e);
  }
}
public abstract void test() throws IOException;
  }
  private static Tester[] tests = { 
new Tester("Stream Write") {
  public void test() throws IOException {
DataOutputStream dos = new DataOutputStream(
  new BufferedOutputStream(
new FileOutputStream(new File("temp.tmp";
for(int i = 0; i < numOfInts; i++)
  dos.writeInt(i);
dos.close();
  }
}, 
new Tester("Mapped Write") {
  public void test() throws IOException {
FileChannel fc = 
  new RandomAccessFile("temp.tmp", "rw")
  .getChannel();
IntBuffer ib = fc.map(
  FileChannel.MapMode.READ_WRITE, 0, fc.size())
  .asIntBuffer();
for(int i = 0; i < numOfInts; i++)
  ib.put(i);
fc.close();
  }
}, 
new Tester("Stream Read") {
  public void test() throws IOException {
DataInputStream dis = new DataInputStream(
  new BufferedInputStream(
new FileInputStream("temp.tmp")));
for(int i = 0; i < numOfInts; i++)
  dis.readInt();
dis.close();
  }
}, 
new Tester("Mapped Read") {
  public void test() throws IOException {
FileChannel fc = new FileInputStream(
  new File("temp.tmp")).getChannel();
IntBuffer ib = fc.map(
  FileChannel.MapMode.READ_ONLY, 0, fc.size())
  .asIntBuffer();
while(ib.hasRemaining())
  ib.get();
fc.close();
  }
}, 
new Tester("Stream Read/Write") {
  public void test() throws IOException {
RandomAccessFile raf = new RandomAccessFile(
  new File("temp.tmp"), "rw");
raf.writeInt(1);
for(int i = 0; i < numOfUbuffInts; i++) {
  raf.seek(raf.length() - 4);
  raf.writeInt(raf.readInt());
}
raf.close();
  }
}, 
new Tester("Mapped Read/Write") {
  public void test() throws IOException {
FileChannel fc = new RandomAccessFile(
  new File("temp.tmp"), "rw").getChannel();
IntBuffer ib = fc.map(
  FileChannel.MapMode.READ_WRITE, 0, fc.size())
  .asIntBuffer();
ib.put(0);
for(int i = 1; i < numOfUbuffInts; i++)
  ib.put(ib.get(i - 1));
fc.close();
  }
}
  };
  public static void main(String[] args) {
for(int i = 0; i < tests.length; i++)
  System.out.println(tests[i].runTest());
  }
} ///:~

RE: JCS Based Cache - how to configure?

[Corin Moss]

Hi Guys,

The more I look at JCS, the more interesting it gets.  The simplest way to use it is 
to simply instantiate a JCS object, and configure it using a "cache configuration 
file" - obviously then the JCS object would be wrapped appropriately.

If we were to use JCS at its most generic level then the user could easily use any 
member store they wanted simply by configuring properly.  The only problem I really 
have is the nature of the configuration.  It is essentially a properties file.  
Obviously this should be done within the cocoon xconf - not an external file.  How 
have you handled this in the past?  Are there any examples I can look at which do 
something similar?

Sorry about the volume of mail - this problem has really caught my interest :)

Thanks,

Corin

-Original Message-
From: Corin Moss
Sent: Tuesday, 2 March 2004 8:59 p.m.
To: [EMAIL PROTECTED]
Subject: RE: JCS Based Cache



You have a good point there - I'm simply going to have to replace the 
DefaultPersistentStore at my end (for testing only of course ;)

One thing that has occurred to me whilst hammering the JISP based store, and looking 
at the code in a bit more depth, is that all of the perceived problems come as a 
result of the incredibly high iowait generated whilst accessing the store (mostly 
while writing I think.)  I notice that the AbstractReadWriteStore within the Excalibur 
components uses FIFOReadWriteLock as the lock - has anyone got much experience with 
this?  If there's a bug in there, it's possible that it's not relinquishing locks 
properly - which would most likely manifest in very high iowait (I theorise ;) I know 
that there are known issues with our version of JISP, but I'd like to be reassured 
first-hand that the read/write lock implementation we're currently using is totally 
robust.

JCS does have its own R/W lock of course - but I'd love not to have to change too many 
classes ;)

Cool,

Corin

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]

Sent: Tuesday, 2 March 2004 8:45 p.m.
To: [EMAIL PROTECTED]
Subject: Re: JCS Based Cache


Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit :

> ... I guess conceptually this really belongs within the
> Avalon-Excalibur-store framework, as it will sit along side

> AbstractJispFilesystemStore rather than on top of it...

Makes sense but I don't think it prevents you from implementing a Store

in the Cocoon source tree for now, like the (broken AFAIK)

org.apache.cocoon.components.store.impl.FilesystemStore which simply

extends AbstractFilesystemStore.

It can always be moved to Avalon later on if needed, but it might be

easier to work on it "here" for now.

What I don't see is how you can configure a different Store than the

DefaultPersistentStore, have you figured this out already? Cocoon uses

DefaultPersistentStore by default but I didn't find where this is

defined.

-Bertrand


CAUTION: This e-mail and any attachment(s) contains information that is intended to be 
read only by the named recipient(s). It may contain information that is confidential, 
proprietary or the subject of legal privilege. This information is not to be used by 
any other person and/or organisation. If you are not the intended recipient, please 
advise us immediately and delete this e-mail from your system. Do not use any 
information contained in it.


For more information on the Television New Zealand Group, visit us online at 
http://www.tvnz.co.nz 


CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

RE: Stream vs Mapped IO (was Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2)

[Carsten Ziegeler]

I'm not against considering 1.4 for 2.2, but please have in mind
that we have to maintain 2.1.x first which is JDK 1.3 based and
we need a replacement for Jisp there.

Carsten 

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jorg Heymans
> Sent: Tuesday, March 02, 2004 9:33 AM
> To: [EMAIL PROTECTED]
> Subject: Stream vs Mapped IO (was Re: [VOTE] - Entry level 
> JSDK 1.4 in Cocoon 2.2)
> 
> Has anyone else read Bruce Eckel's "Thinking in Java" ?
> 
>  (chapter 12)
> Although the performance of "old" stream I/O has been 
> improved by implementing it with nio, mapped file access 
> tends to be dramatically faster.
> 
> 
> So by switching to 1.4 and *not* using NIO you're likely to 
> get a speed bump already.
> 
> However switching to mapped file access (as was suggested 
> before using memory mapped files) from traditional stream IO 
> would gain the most significant increase.
> 
> 
> Stream Write: 1719
> Mapped Write: 359
> Stream Read: 750
> Mapped Read: 125
> Stream Read/Write: 5188
> Mapped Read/Write: 16
> 
> 
> I am getting similar results over various runs. The test 
> program is attached (needs the test harness classes to run, 
> but you can see what he's doing)
> 
> The third edition including code samples is freely available 
> from http://mindview.net/Books/DownloadSites
> 
> I hope this helps making the decision 1.4 vs 1.3. I also 
> started a poll on the userlist to get a feeling of what the 
> installed userbase is using at the moment. I'll gather some 
> stats and report back.
> 
> 
> Regards
> Jorg
> 
> Antonio Gallardo wrote:
> 
> > Hi:
> > 
> > Many was talked about this topic. I think it not need a 
> large explanation:
> > 
> > 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.
> > 
> > Do you agree with JSDK 1.4 as the lower Java version 
> supported in Cocoon 2.2?
> > 
> > Here is my +1
> > 
> > Best Regards,
> > 
> > Antonio Gallardo
> > 
> 

RE: JCS Based Cache - how to configure?

[Carsten Ziegeler]

I think the first solution to see how JCS behaves is to
stick to the properties file. 
If JCS can be configured differently than you could make
the component Parameterizable. 

Carsten 

> -Original Message-
> From: Corin Moss [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 02, 2004 9:34 AM
> To: [EMAIL PROTECTED]
> Subject: RE: JCS Based Cache - how to configure?
> 
> 
> Hi Guys,
> 
> The more I look at JCS, the more interesting it gets.  The 
> simplest way to use it is to simply instantiate a JCS object, 
> and configure it using a "cache configuration file" - 
> obviously then the JCS object would be wrapped appropriately.
> 
> If we were to use JCS at its most generic level then the user 
> could easily use any member store they wanted simply by 
> configuring properly.  The only problem I really have is the 
> nature of the configuration.  It is essentially a properties 
> file.  Obviously this should be done within the cocoon xconf 
> - not an external file.  How have you handled this in the 
> past?  Are there any examples I can look at which do 
> something similar?
> 
> Sorry about the volume of mail - this problem has really 
> caught my interest :)
> 
> Thanks,
> 
> Corin
> 
> -Original Message-
> From: Corin Moss
> 
> Sent: Tuesday, 2 March 2004 8:59 p.m.
> To: [EMAIL PROTECTED]
> Subject: RE: JCS Based Cache
> 
> 
> 
> You have a good point there - I'm simply going to have to 
> replace the DefaultPersistentStore at my end (for testing 
> only of course ;)
> 
> One thing that has occurred to me whilst hammering the JISP 
> based store, and looking at the code in a bit more depth, is 
> that all of the perceived problems come as a result of the 
> incredibly high iowait generated whilst accessing the store 
> (mostly while writing I think.)  I notice that the 
> AbstractReadWriteStore within the Excalibur components uses 
> FIFOReadWriteLock as the lock - has anyone got much 
> experience with this?  If there's a bug in there, it's 
> possible that it's not relinquishing locks properly - which 
> would most likely manifest in very high iowait (I theorise ;) 
> I know that there are known issues with our version of JISP, 
> but I'd like to be reassured first-hand that the read/write 
> lock implementation we're currently using is totally robust.
> 
> JCS does have its own R/W lock of course - but I'd love not 
> to have to change too many classes ;)
> 
> Cool,
> 
> Corin
> 
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> 
> Sent: Tuesday, 2 March 2004 8:45 p.m.
> To: [EMAIL PROTECTED]
> Subject: Re: JCS Based Cache
> 
> 
> Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit :
> 
> > ... I guess conceptually this really belongs within the
> 
> > Avalon-Excalibur-store framework, as it will sit along side
> 
> > AbstractJispFilesystemStore rather than on top of it...
> 
> Makes sense but I don't think it prevents you from 
> implementing a Store
> 
> in the Cocoon source tree for now, like the (broken AFAIK)
> 
> org.apache.cocoon.components.store.impl.FilesystemStore which simply
> 
> extends AbstractFilesystemStore.
> 
> It can always be moved to Avalon later on if needed, but it might be
> 
> easier to work on it "here" for now.
> 
> What I don't see is how you can configure a different Store than the
> 
> DefaultPersistentStore, have you figured this out already? Cocoon uses
> 
> DefaultPersistentStore by default but I didn't find where this is
> 
> defined.
> 
> -Bertrand
> 
> 
> CAUTION: This e-mail and any attachment(s) contains 
> information that is intended to be read only by the named 
> recipient(s). It may contain information that is 
> confidential, proprietary or the subject of legal privilege. 
> This information is not to be used by any other person and/or 
> organisation. If you are not the intended recipient, please 
> advise us immediately and delete this e-mail from your 
> system. Do not use any information contained in it.
> 
> 
> For more information on the Television New Zealand Group, 
> visit us online at http://www.tvnz.co.nz 
> 
> 
> 
> CAUTION: This e-mail and any attachment(s) contains 
> information that is intended to be read only by the named 
> recipient(s). It may contain information that is 
> confidential, proprietary or the subject of legal privilege. 
> This information is not to be used by any other person and/or 
> organisation. If you are not the intended recipient, please 
> advise us immediately and delete this e-mail from your 
> system. Do not use any information contained in it.
> 
> 
> For more information on the Television New Zealand Group, 
> visit us online at htt

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

[Reinhard Pötz]

Geoff Howard wrote:

Ugo Cei wrote:

Antonio Gallardo wrote:

Do you agree with JSDK 1.4 as the lower Java version supported in 
Cocoon 2.2?

Here is my +1


-0.5

Even though 1.4 is available for most platforms, and I've been using 
it exclusively for quite a long time, I still think there are many 
environments where people are forced to use 1.3 (not to mention 1.2) 
and upgrading wouldn't be an easy task.


Does anyone here have any direct experience with such a situation?  I 
am having a hard time imagining a case where a new development effort 
would be forced for technical reasons not to deploy on a newer 
backwards compatible jdk.  Old 1.3 code will run (in some cases after 
recompilation), and old projects can still use whatever jvm version 
they need.  But a new project based on a new version of Cocoon?  Ok, a 
2.1 project may want to upgrade but my experiences have shown 
upgrading jvm generally painless compared to upgrading Cocoon versions...
Yes I have. But I think it's okay if 2.1 has JDK1.3 as minimum JVM and 
Cocoon 2.2 JDK1.4 because it will take some time until the 2.2 branch 
will be released and marked as stable. And I don't think that those 
organizations use unstable software ;-)

--
Reinhard

Re: JCS Based Cache

[Sylvain Wallez]

Bertrand Delacretaz wrote:

Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit :

... I guess conceptually this really belongs within the 
Avalon-Excalibur-store framework, as it will sit along side 
AbstractJispFilesystemStore rather than on top of it...


Makes sense but I don't think it prevents you from implementing a 
Store in the Cocoon source tree for now, like the (broken AFAIK) 
org.apache.cocoon.components.store.impl.FilesystemStore which simply 
extends AbstractFilesystemStore.

It can always be moved to Avalon later on if needed, but it might be 
easier to work on it "here" for now.

What I don't see is how you can configure a different Store than the 
DefaultPersistentStore, have you figured this out already? Cocoon uses 
DefaultPersistentStore by default but I didn't find where this is 
defined.


Hey Bertrand, still asleep?

Have a look in cocoon.roles: it's the default class for the 
"org.apache.excalibur.store.Store/PersistentStore" role.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: JCS Based Cache

[Bertrand Delacretaz]

Le Mardi, 2 mars 2004, à 09:52 Europe/Zurich, Sylvain Wallez a écrit :
...Have a look in cocoon.roles: it's the default class for the  
"org.apache.excalibur.store.Store/PersistentStore" role.
I did
$ find src -type f | xargs grep -i defaultpersistent
and it told me indeed:
src/java/org/apache/cocoon/cocoon.roles:
   
default- 
class="org.apache.cocoon.components.store.impl.DefaultPersistentStore"/ >

so
Hey Bertrand, still asleep?
I guess yes ;-)

sorry for the noise.
-Bertrand

[Solved] Re: [CForms] - Error in binding samples

[Antonio Gallardo]

Sorry, my fault. The samples are working good!

Best Regards,

Antonio Gallardo.

Antonio Gallardo dijo:
> Hi:
>
> Try to send any of these forms:
>
> http://localhost:/samples/woody/form2xml.flow
> http://localhost:/samples/woody/form2bean.flow
>
> They don't show any error, but does not finish the processing (read the
> instructions of the sample). I think there is still a bug.
>
> Best Regards,
>
> Antonio Gallardo
>

RE: patch to Enhance CIncludeTrasnformer to handle encoding ofparameters

[Carsten Ziegeler]

Hi Marco,

I applied the first part (SourceUtil) of your patch. I'm not
sure about the other part (for the CIncludeTransformer).
Can you explain a little bit, why/when this might be necessary?

Thanks
Carsten

> -Original Message-
> From: Marco Dubbeld [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 01, 2004 12:08 PM
> To: [EMAIL PROTECTED]
> Subject: patch to Enhance CIncludeTrasnformer to handle 
> encoding ofparameters
> 
> Hi cocoon developers,
> 
> 1st - Thank you for making cocoon. Cocoon is good stuff, but 
> I guess you know that already. ;) 2nd - I've been using 
> cocoon in a little project for a search page (returns 
> multilingual results), however found some limitation while 
> using the CInclude transformer. I've posted a patch for it under 
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26924
> 
> on 2004-02-13. It had to do with encoding of request 
> parameters. The related patch to excalibur sourceresolver has 
> already been applied.
> 
> Without becoming pushy, just wanted to know if this can be 
> applied..
> 
> Thanks,
> Marco
> 
> 

FW: Non-Ascii from Postgres

[Yves Vindevogel]

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]
Sent: maandag 1 maart 2004 17:35
To: [EMAIL PROTECTED]
Subject: RE: Non-Ascii from Postgres


The encoding thing does not help.  Could this be a bug in 2.1.(4) ?

I checked my connection, it includes charSet=iso-8859-1.
I checked every single file, all have iso-8859-1.

Is there content in the database that cannot be depicted ?

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]
Sent: zondag 29 februari 2004 22:35
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Non-Ascii from Postgres


The iso-8859-1 tag is in my sitemap.

I only have the error on Cocoon 2.1.4 (Jetty on )
When I use another machine that still uses 2.0.xx, with the same database,
it works.

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]
Sent: zondag 29 februari 2004 22:15
To: [EMAIL PROTECTED]
Subject: Non-Ascii from Postgres


Hi,

I get this error from Cocoon 2.1.

org.apache.cocoon.ProcessingException: Exception in
ServerPagesGenerator.generate():
org.apache.avalon.framework.CascadingRuntimeException: Error getting ascii
data for column namenl


It happens when I get non-ascii data from my database.
I only have it on Cocoon 2.1.

I know I have to change the content-type somewhere in my sitemap, but I've
forgotten where.

Somebody a quick hint ??

Yves



-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]
Sent: zondag 29 februari 2004 20:04
To: [EMAIL PROTECTED]
Subject: RE: deleting file


Yes, you are right about that, but this command gives you access to all the
shell commands.

-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: zondag 29 februari 2004 19:58
To: [EMAIL PROTECTED]
Subject: Re: deleting file


Yves Vindevogel wrote:

>Got this once  but you can read what Steven Noels thinks about it ...
>
>Yves Vindevogel wrote:
>
>
>>Is there anything within Cocoon that interacts with the (*nix)-shell ?
>>Or a way to do this ?
>>
>>
>
>System.exec() from Java, but evil as hell. Don't!!!
>
>
>
>

Not sure what that has to do with deleting a file?  A java.io.File
object has a delete() method which has always worked quite well for me!
See http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html

What Stephen was referring to was executing arbitrary shell executables
which is of course non-portable across OSs and has deadlock issues
(though they can be worked around to a great degree).  It's also
aesthetically at odds with the general Java paradigm and so should
really be a last resort.

Geoff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27362] New: - Missing "Last-Modified" in ResourceReader avoids Browser Caching

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27362

Missing "Last-Modified" in ResourceReader avoids Browser Caching

   Summary: Missing "Last-Modified" in ResourceReader avoids Browser
Caching
   Product: Cocoon 2
   Version: 2.0.4
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I saw that images in a page are reloaded on every click when using Mozilla. I
looked for the problem and found that files delivered by "ResourceReader" have
no "last modified" header.

My own Readers which set the Date-Header "Last-Modified" to the correct value,
the problem seems to be solved. This increases Website Performance a lot.

DO NOT REPLY [Bug 27362] - Missing "Last-Modified" in ResourceReader avoids Browser Caching

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27362

Missing "Last-Modified" in ResourceReader avoids Browser Caching





--- Additional Comments From [EMAIL PROTECTED]  2004-03-02 11:31 ---
Could you provide a patch?

[CForm]two question/suggestion about multi-value field

[roy huang]

I was a Notes programmer,when I tried to migrate my application to cocoon using cocoon 
form,I found multi-value field is a problem.I pick two question or suggestion here:
1.In cocoon form multi-value field rendered as listbox or others,but if you want to 
enter in a text input,the value is single.Can/Should cocoon form provide multi-value 
field as text input,using separator like "," or ";" to separate the multi-value?
2.Sometime we need to just display multi-value as text like ,but I only 
found binding can only bind multivalue-field with multi-value(only in cvs 
now).Can/Should cocoon form provide multi-value binding to output widget?Xml source 
like that:
a.xml data

good
morning

b.multi-value field 

,
...

c.output

true
 
...


Roy Huang

Event caching and CachedSource

[Unico Hommes]

Hi gang :-)

A drawback I have been running into lately with eventcache mechanism is 
that it lacks the ability to remove heavy processing from the critical 
path. An event will simply remove a set of cached pipelines from the 
cache completely. Making the subsequent request for such a pipeline 
potentialy very slow. In applications where isolation is not a 
requirement this is an unnecessary drawback.

I am looking at the excellent CachedSource stuff that is in the 
scratchpad area ATM and am wondering how it fits together with the 
eventcache stuff. One thing I am looking into right now is to write an 
EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source wrapper that can 
cache a its delegate. Refreshing can be done either synchronously or 
asynchronously but currently only based upon a specified time-out. What 
I'd like to do is generalize this a bit in order to add the ability to  
externally trigger invalidation.

For this however I think a modification to the Refresher interface is 
needed.

Instead of:

Refresher {
 refresh(key,uri,timeout);
 periodicallyRefresh(key,uri,timeout);
}
I'd like to remove timeout semantics from the interface:

Refresher {
 refresh(key,uri,params);
}
I don't think there is currently a reason for there being two the 
separate methods. So I think we can safely combine them into one. But I 
guess I am looking at Carsten for confirmation... :-)

Cheers,
Unico

RE: Event caching and CachedSource

[Corin Moss]

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
that the "timeout" is used to cache the page on a timed basis a la cron
(although that could be what you mean).

I'm not entirely sure how this helps with external validation directly
:)

What I've been playing around with in this class is a "refreshInFuture"
method which does a one-time-only refresh in x seconds (probably 1
minimum to be safe from expiry problems :)

Does that help you at all? I'm happy to contribute it if it would.

Corin


-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 3 March 2004 12:44 a.m.
To: [EMAIL PROTECTED]
Subject: Event caching and CachedSource


Hi gang :-)

A drawback I have been running into lately with eventcache mechanism is
that it lacks the ability to remove heavy processing from the critical
path. An event will simply remove a set of cached pipelines from the
cache completely. Making the subsequent request for such a pipeline
potentialy very slow. In applications where isolation is not a
requirement this is an unnecessary drawback.

I am looking at the excellent CachedSource stuff that is in the
scratchpad area ATM and am wondering how it fits together with the
eventcache stuff. One thing I am looking into right now is to write an
EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source wrapper that can
cache a its delegate. Refreshing can be done either synchronously or
asynchronously but currently only based upon a specified time-out. What
I'd like to do is generalize this a bit in order to add the ability to 
externally trigger invalidation.

For this however I think a modification to the Refresher interface is
needed.

Instead of:

Refresher {
  refresh(key,uri,timeout);
  periodicallyRefresh(key,uri,timeout);
}

I'd like to remove timeout semantics from the interface:

Refresher {
  refresh(key,uri,params);
}

I don't think there is currently a reason for there being two the
separate methods. So I think we can safely combine them into one. But I
guess I am looking at Carsten for confirmation... :-)

Cheers,
Unico



CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

RE: Event caching and CachedSource

[Carsten Ziegeler]

Unico Hommes wrote:
> 
> Hi gang :-)
> 
> A drawback I have been running into lately with eventcache 
> mechanism is that it lacks the ability to remove heavy 
> processing from the critical path. An event will simply 
> remove a set of cached pipelines from the cache completely. 
> Making the subsequent request for such a pipeline potentialy 
> very slow. In applications where isolation is not a 
> requirement this is an unnecessary drawback.
> 
> I am looking at the excellent CachedSource stuff that is in 
> the scratchpad area ATM and am wondering how it fits together 
> with the eventcache stuff. One thing I am looking into right 
> now is to write an EventAware Refresher implementation.
> 
> For those unfamiliar with CachedSource, it is a Source 
> wrapper that can cache a its delegate. Refreshing can be done 
> either synchronously or asynchronously but currently only 
> based upon a specified time-out. What I'd like to do is 
> generalize this a bit in order to add the ability to 
> externally trigger invalidation.
> 
> For this however I think a modification to the Refresher 
> interface is needed.
> 
> Instead of:
> 
> Refresher {
>   refresh(key,uri,timeout);
>   periodicallyRefresh(key,uri,timeout);
> }
> 
> I'd like to remove timeout semantics from the interface:
> 
> Refresher {
>   refresh(key,uri,params);
> }
> 
> I don't think there is currently a reason for there being two 
> the separate methods. So I think we can safely combine them 
> into one. But I guess I am looking at Carsten for confirmation... :-)
> 
Although you actually don't need my confirmation as it's not my
but *our* source, here it is :)
I think this makes sense and I think we should also move this
out of the scratchpad afterwards as well.

Carsten

RE: patch to Enhance CIncludeTrasnformer to handle encoding ofparameters

[Marco Dubbeld]

Yep! The value element may contain UTF-8, with chinese characters or
other non ISO-8859 encoding characters. While testing, the 

this.startSerializedXMLRecording(XMLUtils.defaultSerializeToXMLFormat(true)); 
will use ISO-8859 encoding (see the properties given back from
XMLUtils). However we should use a property set with the encoding from
the document we are transforming. Otherwise this causes
UTFDataFormatException for chinese UTF-8 for example.

To use xml recording for a cinclude value element did not make sense to
me anyways, so I choose to use text recording instead to prevent the
problem. 

Thanks,
Marco




On Tue, 2004-03-02 at 10:51, Carsten Ziegeler wrote:
> Hi Marco,
> 
> I applied the first part (SourceUtil) of your patch. I'm not
> sure about the other part (for the CIncludeTransformer).
> Can you explain a little bit, why/when this might be necessary?
> 
> Thanks
> Carsten
> 
> > -Original Message-
> > From: Marco Dubbeld [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, March 01, 2004 12:08 PM
> > To: [EMAIL PROTECTED]
> > Subject: patch to Enhance CIncludeTrasnformer to handle 
> > encoding ofparameters
> > 
> > Hi cocoon developers,
> > 
> > 1st - Thank you for making cocoon. Cocoon is good stuff, but 
> > I guess you know that already. ;) 2nd - I've been using 
> > cocoon in a little project for a search page (returns 
> > multilingual results), however found some limitation while 
> > using the CInclude transformer. I've posted a patch for it under 
> > 
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26924
> > 
> > on 2004-02-13. It had to do with encoding of request 
> > parameters. The related patch to excalibur sourceresolver has 
> > already been applied.
> > 
> > Without becoming pushy, just wanted to know if this can be 
> > applied..
> > 
> > Thanks,
> > Marco
> > 
> > 

Re: Event caching and CachedSource

[Geoff Howard]

Unico Hommes wrote:

Hi gang :-)

A drawback I have been running into lately with eventcache mechanism 
is that it lacks the ability to remove heavy processing from the 
critical path. An event will simply remove a set of cached pipelines 
from the cache completely. Making the subsequent request for such a 
pipeline potentialy very slow. In applications where isolation is not 
a requirement this is an unnecessary drawback.


Below sounds interesting and good but I haven't understood how event 
cache is related.  AFAICS the only difference with eventcache and the 
other validity types is that for the others an invalid response is found 
in cache, but not used because it is found invalid after retrieval, but 
the event cache removes the entry at invalidation time since it knows it 
will never be useful.  Both cases mean that the next person to request 
that resource will have to wait for the full generation.  Maybe because 
I've only glanced at the refresher stuff?

Bottom line for me at moment is: do you foresee a need to modify the 
eventcache API to accomodate this need?  I'm getting ready to start a 
discussion on changing the eventcache unstable status -- should I hold off?

I am looking at the excellent CachedSource stuff that is in the 
scratchpad area ATM and am wondering how it fits together with the 
eventcache stuff. One thing I am looking into right now is to write an 
EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source wrapper that 
can cache a its delegate. Refreshing can be done either synchronously 
or asynchronously but currently only based upon a specified time-out. 
What I'd like to do is generalize this a bit in order to add the 
ability to  externally trigger invalidation.

For this however I think a modification to the Refresher interface is 
needed.


BTW, how does CachedSource accomplish something different from the 
caching point pipeline (which seems to accomplish more, though I've 
never used it).

Geoff

RE: patch to Enhance CIncludeTrasnformer to handle encodingofparameters

[Carsten Ziegeler]

Marco Dubbeld wrote:
> 
> Yep! The value element may contain UTF-8, with chinese 
> characters or other non ISO-8859 encoding characters. While 
> testing, the 
> 
> this.startSerializedXMLRecording(XMLUtils.defaultSerializeToXM
> LFormat(true));
> will use ISO-8859 encoding (see the properties given back 
> from XMLUtils). However we should use a property set with the 
> encoding from the document we are transforming. Otherwise 
> this causes UTFDataFormatException for chinese UTF-8 for example.

So the best way would be to pass the encoding of the document
to the XMLUtils used for serializing. Is this possible?

> 
> To use xml recording for a cinclude value element did not 
> make sense to me anyways, so I choose to use text recording 
> instead to prevent the problem. 
> 
Yes, that's true, I'm wondering about that as well. But unfortunately
your change is incompatible - although I think it doesn't affect
someone.

Carsten 

Re: [RT] rethinking the cache storage system

[Pier Fumagalli]

On 2 Mar 2004, at 05:29, Mircea Toma wrote:

Stefano Mazzocchi wrote:
We were using Jisp and Scott's decision makes it clear that we either:
 - have to maintain Jisp 2.x ourselves
or
 - use something else
How about http://jdbm.sourceforge.net/ ? It implements the B+Tree 
algorithm. B+Tree is a better indexing mechanism than BTree, because 
the indexes can be cached in memory. JDBM has a BSD license also.
Decent starting point... I used to work with the guy who wrote it: Alex 
Boisvert (Intalio). Now, if it only implemented the java.util.Map 
interface, and used NIO, THAT would be so cool! :-D

	Pier

DO NOT REPLY [Bug 27362] - Missing "Last-Modified" in ResourceReader avoids Browser Caching

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27362

Missing "Last-Modified" in ResourceReader avoids Browser Caching





--- Additional Comments From [EMAIL PROTECTED]  2004-03-02 12:46 ---
Sure, but i don't have cvs (write-) access. It's just a few lines to add:

File: src/java/org/apache/cocoon/reading/ResourceReader.java

Add below the lines
---
if (expires > 0) {
response.setDateHeader("Expires", System.currentTimeMillis() + expires);
}
---

this code:

---
final long lastModified=getLastModified();
if (lastModified > 0) {
response.setDateHeader("Last-Modified", lastModified);
}
---

This solves the problem for me (i got this code from my own reader but it should
also work with ResourceReader).

Re: Event caching and CachedSource

[Unico Hommes]

Carsten Ziegeler wrote:

Unico Hommes wrote:
 

Hi gang :-)

A drawback I have been running into lately with eventcache 
mechanism is that it lacks the ability to remove heavy 
processing from the critical path. An event will simply 
remove a set of cached pipelines from the cache completely. 
Making the subsequent request for such a pipeline potentialy 
very slow. In applications where isolation is not a 
requirement this is an unnecessary drawback.

I am looking at the excellent CachedSource stuff that is in 
the scratchpad area ATM and am wondering how it fits together 
with the eventcache stuff. One thing I am looking into right 
now is to write an EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source 
wrapper that can cache a its delegate. Refreshing can be done 
either synchronously or asynchronously but currently only 
based upon a specified time-out. What I'd like to do is 
generalize this a bit in order to add the ability to 
externally trigger invalidation.

For this however I think a modification to the Refresher 
interface is needed.

Instead of:

Refresher {
 refresh(key,uri,timeout);
 periodicallyRefresh(key,uri,timeout);
}
I'd like to remove timeout semantics from the interface:

Refresher {
 refresh(key,uri,params);
}
I don't think there is currently a reason for there being two 
the separate methods. So I think we can safely combine them 
into one. But I guess I am looking at Carsten for confirmation... :-)

   

Although you actually don't need my confirmation as it's not my
but *our* source, here it is :)
 

OK, thanks. Just trying exclude the possibility of overlooking something 
and allowing you the oppertunity to comment on any changes beforehand.

I think this makes sense and I think we should also move this
out of the scratchpad afterwards as well.
 

OK, agreed. But where should it go.

Unico

Re: Event caching and CachedSource

[Unico Hommes]

Geoff Howard wrote:

Unico Hommes wrote:

Hi gang :-)

A drawback I have been running into lately with eventcache mechanism 
is that it lacks the ability to remove heavy processing from the 
critical path. An event will simply remove a set of cached pipelines 
from the cache completely. Making the subsequent request for such a 
pipeline potentialy very slow. In applications where isolation is not 
a requirement this is an unnecessary drawback.


Below sounds interesting and good but I haven't understood how event 
cache is related.  AFAICS the only difference with eventcache and the 
other validity types is that for the others an invalid response is 
found in cache, but not used because it is found invalid after 
retrieval, but the event cache removes the entry at invalidation time 
since it knows it will never be useful.  Both cases mean that the next 
person to request that resource will have to wait for the full 
generation.  Maybe because I've only glanced at the refresher stuff?

I guess you are right that at the Cache level nothing really changes. I 
overlooked that fact. I will do some more research on what is required 
to accomplish that in the case of the Refresher, but my idea was that 
the cached response would be served until a newly generated one could 
replace the stale one. Since the Refresher talks to the Cache directly, 
given the correct Validity strategy it can exercise full control over it.

Bottom line for me at moment is: do you foresee a need to modify the 
eventcache API to accomodate this need?  I'm getting ready to start a 
discussion on changing the eventcache unstable status -- should I hold 
off?

I don't think my current work will influence the eventcache API 
directly. Although I am not sure if
the eventcache stuff can be considered stable enough. I still have some 
doubts about the ease of use of parts of it especially the way events 
are associated with cached objects. But lets discuss that separately.

I am looking at the excellent CachedSource stuff that is in the 
scratchpad area ATM and am wondering how it fits together with the 
eventcache stuff. One thing I am looking into right now is to write 
an EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source wrapper that 
can cache a its delegate. Refreshing can be done either synchronously 
or asynchronously but currently only based upon a specified time-out. 
What I'd like to do is generalize this a bit in order to add the 
ability to  externally trigger invalidation.

For this however I think a modification to the Refresher interface is 
needed.


BTW, how does CachedSource accomplish something different from the 
caching point pipeline (which seems to accomplish more, though I've 
never used it).

I never used it either. So I really don't know. Perhaps someone else 
could comment on this?

Cheers,
Unico

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

Ugo Cei wrote:

Unico Hommes wrote:

I think that as a software product that is known for its innovative 
nature it is *very* important in the interest of Cocoon to refuse 
being impaired by the immobility of bureaucracratic organisations. 
We are having a small crisis on our hands ATM regarding our 
persistent store component and if I was reading Pier correctly he 
was willing to dedicate some time towards a solution to this problem.

One of the main attractions of the jdk 1.4 is its NIO package, and 
it's supposed to be a major improvement in Javas IO performance. 
With 1.4 being available for - what more than two years? - and 1.5 
already on the horizon it is IMHO the right time to upgrade.


Since we don't have a NIO-based implementation of the persistent 
store, yet, why upgrade now? When we have it, I'll be more than 
willing to vote +1.


Ugo,

this is chicken-egg problem: nobody is going to implement something on 
1.4-only API if they aren't sure the community is going to accept it.

We don't have to decide right now, but I think it would be good to 
give the signal "please go ahead and experiment if you think it makes 
sense, we'll judge depending on the advantages".

WDYT?


Agreed. But, please, somebody, [POLL] our userbase first.

Vadim

RE: Event caching and CachedSource

[Carsten Ziegeler]

Unico Hommes wrote:

> > BTW, how does CachedSource accomplish something different from the 
> > caching point pipeline (which seems to accomplish more, though I've 
> > never used it).
> >
> I never used it either. So I really don't know. Perhaps 
> someone else could comment on this?
> 
The CachedSource caches a source :) whereas the caching point pipeline
caches part of a pipeline. They could be used in combination but have
different purposes.
The caching point pipeline can cache the beginning of a pipeline upto
the point, but this only works if all components in the pipeline
support the caching; if not, nothing is cached.

Now, imagine that you have a database source that fetches content
from a slow database (or cms). The usual caching alg. tries to
look if the source read by the generator has changed since the last call.
In the case of the database source this is not possible and the
pipeline is never cached.
With the cached source the content fetched from the db is cached,
reducing the requests to the back-end system and the generator
can use this to test if the source has changed, allowing the
pipeline (or a part of it) to be cached as well.

HTH
Carsten

Re: Change from 80 cpl to 100 cpl standard

[Vadim Gritsenko]

Antonio Gallardo wrote:

Vadim Gritsenko dijo:
 

I, for myself, moved to somewhere around 100 characters per line. With
long Java identifiers it's not much you can fit in 80 chars ;-)
   

Yep. I agree with you. The 80 cpl (cols per line) is an old "standard" and
we can change it if everybody agree on the Cocoon community. Need we vote
for this? I am +1 for change to "100 cpl".
The 80 cols per line was setted also to match printed version of code. But
I am not sure if still somebody is printing code for storage. I use CD's
to save the trees.
WDYT?
 

I think "use your best judgement" and I also think "don't use automatic 
code formatting tools, but rather format bad offenders (like > 120 char 
lines) only in the pieces of code you are working on" :-)

Vadim

Re: [CForm]two question/suggestion about multi-value field

[Vadim Gritsenko]

roy huang wrote:

>1.In cocoon form multi-value field rendered as listbox or others,but if you want to 
>enter in a text input,the value is single. Can/Should cocoon form provide multi-value 
>field as text input,using separator like "," or ";" to separate the multi-value?
>  
>

My first reaction: No way! Using separator is totally user un-friendly,
from my POV. But what actually should/could happen, is that you can
render multiple input boxes. You could even specify count of such boxes
using wi:styling


>2.Sometime we need to just display multi-value as text like ,but I only 
>found binding can only bind multivalue-field with multi-value(only in cvs 
>now).Can/Should cocoon form provide multi-value binding to output widget?
>

I think no. Why do you want to bind it to wd:output? If you want to
*render* it as text output, you should use wi:styling type=output.

Vadim

Re: whitespace cleanup and efficiency drive

[Vadim Gritsenko]

David Crossley wrote:

David Crossley wrote:
 

...

We have quite a number of these problem files in cocoon-2.1
I noticed a new one come in today with Carsten's commit
of portal.samplesxconf
   

The recent commit of all the *.license files proved that Eclipse
is the culprit. Until their Bug 15119 is fixed (please vote for it),
the Eclipse users should use the workaround to add the unknown
text types.
The find_binary_text.pl script reports these problems:
.ai
.css
.dtd
.gt
.in
 

...

You know that you can use cvs admin to change keyword substitution, right?

Vadim

[1] http://blog.reverycodes.com/archives/07.html

Re: Event caching and CachedSource

[Geoff Howard]

Unico Hommes wrote:

Geoff Howard wrote:

Unico Hommes wrote:

Hi gang :-)

A drawback I have been running into lately with eventcache mechanism 
is that it lacks the ability to remove heavy processing from the 
critical path. An event will simply remove a set of cached pipelines 
from the cache completely. Making the subsequent request for such a 
pipeline potentialy very slow. In applications where isolation is 
not a requirement this is an unnecessary drawback.


Below sounds interesting and good but I haven't understood how event 
cache is related.  AFAICS the only difference with eventcache and the 
other validity types is that for the others an invalid response is 
found in cache, but not used because it is found invalid after 
retrieval, but the event cache removes the entry at invalidation time 
since it knows it will never be useful.  Both cases mean that the 
next person to request that resource will have to wait for the full 
generation.  Maybe because I've only glanced at the refresher stuff?

I guess you are right that at the Cache level nothing really changes. 
I overlooked that fact. I will do some more research on what is 
required to accomplish that in the case of the Refresher, but my idea 
was that the cached response would be served until a newly generated 
one could replace the stale one. Since the Refresher talks to the 
Cache directly, given the correct Validity strategy it can exercise 
full control over it.


So, stale entries are served until they can be regenerated?  I've looked 
for this in the past (someone called it the "I'm Sorry" pattern :) ) and 
at the time thought it might be better implemented by a pluggable 
strategy at the pipeline execution level.  Currently we have:

- Assemble Pipeline
- Gather key from Pipeline
- Check cache for key
- If object for key found, check its validity
- If valid, serve the cached response
- Else, execute pipeline and serve it.
the cache point pipeline, and the non-caching pipeline are other 
implementations of different strategies, but are accomplished by 
inheritance instead of composing a Strategy.  I haven't ever thought it 
through carefully but it seems like making those last 5 steps (as a 
group) a pluggable strategy would allow things like this "I'm Sorry" 
pattern, as well as more powerful concepts like Stefano's proposed 
adaptive cache.  Just raw thoughts at this point...

Bottom line for me at moment is: do you foresee a need to modify the 
eventcache API to accomodate this need?  I'm getting ready to start a 
discussion on changing the eventcache unstable status -- should I 
hold off?

I don't think my current work will influence the eventcache API 
directly. Although I am not sure if
the eventcache stuff can be considered stable enough. I still have 
some doubts about the ease of use of parts of it especially the way 
events are associated with cached objects. But lets discuss that 
separately.


Ah, good.  Ok, I'll pick up on another thread.

Geoff

Re: Event caching and CachedSource

[Unico Hommes]

Corin Moss wrote:

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
that the "timeout" is used to cache the page on a timed basis a la cron
(although that could be what you mean).
I'm not entirely sure how this helps with external validation directly
:)
What I've been playing around with in this class is a "refreshInFuture"
method which does a one-time-only refresh in x seconds (probably 1
minimum to be safe from expiry problems :)
Does that help you at all? I'm happy to contribute it if it would.

 

Hmm, I guess my explanation was a little bit dense. Let me put this into 
context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav repository. 
Obviously this introduces some network overhead and particular parts of 
the site can get slow to generate. Especially those generated using 
TraversableGenerators.

Traditional caching requires the objects on behalf of which it caches to 
provide a so called Validity object in order to determine whether its 
cached objects are still valid upon subsequent request. Most sources 
will try to determine this by providing a last modifed timestamp the 
cache can compare. Since retrieving the last modification time is an 
expensive operation in the case of a webdav source determining the 
validity of a cached response would be almost as expensive as generating 
a new response, requiring a webdav propfind for each source that is a 
member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the 
Cache that the source is always valid using a special Validity object. 
Cache invalidation will be accomplished by an external event triggering 
the removal of all pipelines the Source is associated with. This means 
though that a subsequent request will be slow since nothing is cached 
anymore.

Perhaps even more importantly, since the pipelines can be huge objects 
the generation of which potentially requires many network calls it is 
much better to cache objects at the most atomic level: the source. Hence 
my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so that 
an external event (say, someone saving a document in the webdav 
repository) will trigger the retrieval of a fresh one. But in the 
background, away from the critical path (asynchronous).

Hope that explains it better.

Unico

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

[Antonio Gallardo]

Vadim Gritsenko dijo:
> Agreed. But, please, somebody, [POLL] our userbase first.

There is already a pool. See the [POLL] in the user list.

Best Regards,

Antonio Gallardo

RE: Event caching and CachedSource

[Corin Moss]

Hi,

That makes perfect sense. I implemented exactly that this week, although
I have to admit it is nowhere near as elegant as I would like.

Basically in my case it's a database update / delete / insert triggering
a cache clear, it is then a specific request generating the re-cache.

I'm then employing something similar to the "I'm sorry" method mentioned
previously.  I've re-implemented the "test" cron job, using a new method
on RefresherImpl which as I mentioned before, caches in the future (by
adding a new scheduled job.) 

Effectively the request to trigger the re-cache might take a few
milliseconds, but the job to recache the page goes on in the background
for as longs as it takes.

At this point, it is simply a call to an internal URL on loopback (very
messy.)  However, I see no reason that something like the XSPUtil
include source couldn't be used.  It would also pay to have a look at
the BackgroundEnvironment - its only weakness is (as commented) that it
doesn't support objects which try to access specific HTTPenvironment
things (object maps etc.)

Like I said - I've got this working at the moment - let me know if you
want the code :)

Corin


-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 3 March 2004 2:39 a.m.
To: [EMAIL PROTECTED]
Subject: Re: Event caching and CachedSource


Corin Moss wrote:

>Hiya,
>
>I'm probably wrong here, but my understanding of the RefresherImpl is
>that the "timeout" is used to cache the page on a timed basis a la cron

>(although that could be what you mean).
>
>I'm not entirely sure how this helps with external validation directly
>:)
>
>What I've been playing around with in this class is a "refreshInFuture"

>method which does a one-time-only refresh in x seconds (probably 1
>minimum to be safe from expiry problems :)
>
>Does that help you at all? I'm happy to contribute it if it would.
>
> 
>

Hmm, I guess my explanation was a little bit dense. Let me put this into

context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav repository.
Obviously this introduces some network overhead and particular parts of
the site can get slow to generate. Especially those generated using
TraversableGenerators.

Traditional caching requires the objects on behalf of which it caches to

provide a so called Validity object in order to determine whether its
cached objects are still valid upon subsequent request. Most sources
will try to determine this by providing a last modifed timestamp the
cache can compare. Since retrieving the last modification time is an
expensive operation in the case of a webdav source determining the
validity of a cached response would be almost as expensive as generating

a new response, requiring a webdav propfind for each source that is a
member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the
Cache that the source is always valid using a special Validity object.
Cache invalidation will be accomplished by an external event triggering
the removal of all pipelines the Source is associated with. This means
though that a subsequent request will be slow since nothing is cached
anymore.

Perhaps even more importantly, since the pipelines can be huge objects
the generation of which potentially requires many network calls it is
much better to cache objects at the most atomic level: the source. Hence

my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so that
an external event (say, someone saving a document in the webdav
repository) will trigger the retrieval of a fresh one. But in the
background, away from the critical path (asynchronous).

Hope that explains it better.

Unico


CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

Re: Momento and Cocoon

[Alan]

* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 06:07]:

> Please stop replying to me directly, I far prefer if you reply to the 
> list, thanks.

Sorry.

> Alan wrote:
> 
> >Yes. I choose Saxon to implement XQuery. I'm finding that XSLT is
> >just as good a query language, that's why I keep using XSLT in
> >my generator examples. Not mixing concerns, it is data store +
> >query, which strikes me as resonable parameters to a generator.

> You can use xslt as a template language for generators but it feels akward.

It makes a lot of sense to me now. XQuery support is there, and
it works, but XSLT does the same thing, and saves the trouble of
learning a new language.

> >>I don't know if momento is good enough for what we need, but if we were 
> >>to have an xquery processor, a generator is the way to go, not a source.
> >
> >
> >What do you need from Momento?
> 
> I need a fast and scalable xquery-capable semi-structured content 
> repository.
> 
> Can momento provide me that?

It could. If I were to release it open source. That's the point.
That's why I'm engaging people on this list.

-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

Re: Event caching and CachedSource

[Geoff Howard]

Unico Hommes wrote:

Corin Moss wrote:

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
that the "timeout" is used to cache the page on a timed basis a la cron
(although that could be what you mean).
I'm not entirely sure how this helps with external validation directly
:)
What I've been playing around with in this class is a "refreshInFuture"
method which does a one-time-only refresh in x seconds (probably 1
minimum to be safe from expiry problems :)
Does that help you at all? I'm happy to contribute it if it would.

 

Hmm, I guess my explanation was a little bit dense. Let me put this 
into context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav repository. 
Obviously this introduces some network overhead and particular parts 
of the site can get slow to generate. Especially those generated using 
TraversableGenerators.

Traditional caching requires the objects on behalf of which it caches 
to provide a so called Validity object in order to determine whether 
its cached objects are still valid upon subsequent request. Most 
sources will try to determine this by providing a last modifed 
timestamp the cache can compare. Since retrieving the last 
modification time is an expensive operation in the case of a webdav 
source determining the validity of a cached response would be almost 
as expensive as generating a new response, requiring a webdav propfind 
for each source that is a member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the 
Cache that the source is always valid using a special Validity object. 
Cache invalidation will be accomplished by an external event 
triggering the removal of all pipelines the Source is associated with. 
This means though that a subsequent request will be slow since nothing 
is cached anymore.

Perhaps even more importantly, since the pipelines can be huge objects 
the generation of which potentially requires many network calls it is 
much better to cache objects at the most atomic level: the source. 
Hence my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so 
that an external event (say, someone saving a document in the webdav 
repository) will trigger the retrieval of a fresh one. But in the 
background, away from the critical path (asynchronous).

Hope that explains it better.


Ok, I'm done being dense - I get this now.  My last response about 
pluggable cache strategies at the pipeline level is totally mismatched.  
At the Source level you don't have to worry about re-assembling the 
pipeline, so all you would have to do is re-cache the source when it is 
invalidated externally.

Can you just handle this when the JMS/other event comes in?  Currently 
it's just translated to an Event and sent to the Cache, but you could 
also contact the Source as well at that point?  Where does the Source 
cache its data?  In memory in a private member, or in the Store?

Geoff

RE: patch to Enhance CIncludeTrasnformer to handle encodingofparameters

[Marco Dubbeld]

On Tue, 2004-03-02 at 13:29, Carsten Ziegeler wrote:
> Marco Dubbeld wrote:
> > 
> > Yep! The value element may contain UTF-8, with chinese 
> > characters or other non ISO-8859 encoding characters. While 
> > testing, the 
> > 
> > this.startSerializedXMLRecording(XMLUtils.defaultSerializeToXM
> > LFormat(true));
> > will use ISO-8859 encoding (see the properties given back 
> > from XMLUtils). However we should use a property set with the 
> > encoding from the document we are transforming. Otherwise 
> > this causes UTFDataFormatException for chinese UTF-8 for example.
> 
> So the best way would be to pass the encoding of the document
> to the XMLUtils used for serializing. Is this possible?
Properties props = XMLUtils.defaultSerializeToXMLFormat(true);
String encoding = ??
props.set(OutputKeys.ENCODING, encoding);
this.startSerializedXMLRecording(props);

How to determine most properly the encoding of the events or the input
source I do not precisly know.
java.sun.com is down from my location so one half of my brains is
blocked. If it's back I try to search. 

Maybe someone on the list knows ?


> 
> > 
> > To use xml recording for a cinclude value element did not 
> > make sense to me anyways, so I choose to use text recording 
> > instead to prevent the problem. 
> > 
> Yes, that's true, I'm wondering about that as well. But unfortunately
> your change is incompatible - although I think it doesn't affect
> someone.
> 
> Carsten 

Re: Event caching and CachedSource

[Unico Hommes]

Geoff Howard wrote:

Unico Hommes wrote:

Geoff Howard wrote:

Unico Hommes wrote:

Hi gang :-)

A drawback I have been running into lately with eventcache 
mechanism is that it lacks the ability to remove heavy processing 
from the critical path. An event will simply remove a set of cached 
pipelines from the cache completely. Making the subsequent request 
for such a pipeline potentialy very slow. In applications where 
isolation is not a requirement this is an unnecessary drawback.


Below sounds interesting and good but I haven't understood how event 
cache is related.  AFAICS the only difference with eventcache and 
the other validity types is that for the others an invalid response 
is found in cache, but not used because it is found invalid after 
retrieval, but the event cache removes the entry at invalidation 
time since it knows it will never be useful.  Both cases mean that 
the next person to request that resource will have to wait for the 
full generation.  Maybe because I've only glanced at the refresher 
stuff?

I guess you are right that at the Cache level nothing really changes. 
I overlooked that fact. I will do some more research on what is 
required to accomplish that in the case of the Refresher, but my idea 
was that the cached response would be served until a newly generated 
one could replace the stale one. Since the Refresher talks to the 
Cache directly, given the correct Validity strategy it can exercise 
full control over it.


So, stale entries are served until they can be regenerated?  I've 
looked for this in the past (someone called it the "I'm Sorry" pattern 
:) ) and at the time thought it might be better implemented by a 
pluggable strategy at the pipeline execution level.  Currently we have:

- Assemble Pipeline
- Gather key from Pipeline
- Check cache for key
- If object for key found, check its validity
- If valid, serve the cached response
- Else, execute pipeline and serve it.
the cache point pipeline, and the non-caching pipeline are other 
implementations of different strategies, but are accomplished by 
inheritance instead of composing a Strategy.  I haven't ever thought 
it through carefully but it seems like making those last 5 steps (as a 
group) a pluggable strategy would allow things like this "I'm Sorry" 
pattern, as well as more powerful concepts like Stefano's proposed 
adaptive cache.  Just raw thoughts at this point...


I see two things at stake in my use case. The strategy pattern as you 
call it (regular,inverted,'i'm sorry', adaptive,etc.) and the 
granularity of  objects in the cache. In my case it is very inefficient 
to only cache complete pipelines and I need to have multiple levels of 
caching to optimize performance: besides caching the complete pipeline, 
also the individual sources that compise a traversable generation.

I am not sure I understand what you mean with 'pluggable strategy'. 
Isn't this what we already have with the different pipeline implementations?

Unico

Re: Momento and Cocoon

[Stefano Mazzocchi]

Alan wrote:

* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 06:07]:

I need a fast and scalable xquery-capable semi-structured content 
repository.

Can momento provide me that?


It could. If I were to release it open source. That's the point.
That's why I'm engaging people on this list.
It could seems like a pretty big overestimation without reasonable 
technological backup.

At least three research groups spent 10 years and millions of dollars 
trying to build an equivalent system. One of them died (Lore) [but the 
source code disappeared so I suspect some big DBMS vendor bought the 
thing], the other went commercial [Xyleme], the other is still 
researching [the people at Bell Labs]

Don't get me wrong: I know the power of open source and I know that you 
need to start somewhere, that's why I'm asking.

What I don't understand is how you can use Saxon as a fast and scalable 
database since it wasn't designed to do so.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Event caching and CachedSource

[Unico Hommes]

Geoff Howard wrote:

Unico Hommes wrote:

Corin Moss wrote:

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
that the "timeout" is used to cache the page on a timed basis a la cron
(although that could be what you mean).
I'm not entirely sure how this helps with external validation directly
:)
What I've been playing around with in this class is a "refreshInFuture"
method which does a one-time-only refresh in x seconds (probably 1
minimum to be safe from expiry problems :)
Does that help you at all? I'm happy to contribute it if it would.

 

Hmm, I guess my explanation was a little bit dense. Let me put this 
into context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav repository. 
Obviously this introduces some network overhead and particular parts 
of the site can get slow to generate. Especially those generated 
using TraversableGenerators.

Traditional caching requires the objects on behalf of which it caches 
to provide a so called Validity object in order to determine whether 
its cached objects are still valid upon subsequent request. Most 
sources will try to determine this by providing a last modifed 
timestamp the cache can compare. Since retrieving the last 
modification time is an expensive operation in the case of a webdav 
source determining the validity of a cached response would be almost 
as expensive as generating a new response, requiring a webdav 
propfind for each source that is a member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the 
Cache that the source is always valid using a special Validity 
object. Cache invalidation will be accomplished by an external event 
triggering the removal of all pipelines the Source is associated 
with. This means though that a subsequent request will be slow since 
nothing is cached anymore.

Perhaps even more importantly, since the pipelines can be huge 
objects the generation of which potentially requires many network 
calls it is much better to cache objects at the most atomic level: 
the source. Hence my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so 
that an external event (say, someone saving a document in the webdav 
repository) will trigger the retrieval of a fresh one. But in the 
background, away from the critical path (asynchronous).

Hope that explains it better.


Ok, I'm done being dense - I get this now. 


Sorry it wasn't meant to suggest you or anybody was being dense. Just 
that my explanation was overly concise.;-)

My last response about pluggable cache strategies at the pipeline 
level is totally mismatched.  At the Source level you don't have to 
worry about re-assembling the pipeline, so all you would have to do is 
re-cache the source when it is invalidated externally.


Exactly.

Can you just handle this when the JMS/other event comes in?  Currently 
it's just translated to an Event and sent to the Cache, but you could 
also contact the Source as well at that point?  Where does the Source 
cache its data?  In memory in a private member, or in the Store?


You got it! (in the Cache/Store)

Unico

Re: Event caching and CachedSource

[Unico Hommes]

Corin Moss wrote:

Hi,

That makes perfect sense. I implemented exactly that this week, although
I have to admit it is nowhere near as elegant as I would like.
Basically in my case it's a database update / delete / insert triggering
a cache clear, it is then a specific request generating the re-cache.
I'm then employing something similar to the "I'm sorry" method mentioned
previously.  I've re-implemented the "test" cron job, using a new method
on RefresherImpl which as I mentioned before, caches in the future (by
adding a new scheduled job.) 

Effectively the request to trigger the re-cache might take a few
milliseconds, but the job to recache the page goes on in the background
for as longs as it takes.
At this point, it is simply a call to an internal URL on loopback (very
messy.)  However, I see no reason that something like the XSPUtil
include source couldn't be used.  It would also pay to have a look at
the BackgroundEnvironment - its only weakness is (as commented) that it
doesn't support objects which try to access specific HTTPenvironment
things (object maps etc.)
 

I am not sure I get the whole picture yet but why do you need internal 
processing? Does this mean you cache cocoon: sources? That does not 
sound appropriate.

Like I said - I've got this working at the moment - let me know if you
want the code :)
 

Yes please, "show me the code!" ;-)

Unico

Corin

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 3 March 2004 2:39 a.m.
To: [EMAIL PROTECTED]
Subject: Re: Event caching and CachedSource
Corin Moss wrote:

 

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
   

 

that the "timeout" is used to cache the page on a timed basis a la cron
   

 

(although that could be what you mean).

I'm not entirely sure how this helps with external validation directly
:)
What I've been playing around with in this class is a "refreshInFuture"
   

 

method which does a one-time-only refresh in x seconds (probably 1
   

 

minimum to be safe from expiry problems :)

Does that help you at all? I'm happy to contribute it if it would.

   

 

Hmm, I guess my explanation was a little bit dense. Let me put this into

context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav repository.

Obviously this introduces some network overhead and particular parts of

the site can get slow to generate. Especially those generated using

TraversableGenerators.

Traditional caching requires the objects on behalf of which it caches to

provide a so called Validity object in order to determine whether its

cached objects are still valid upon subsequent request. Most sources

will try to determine this by providing a last modifed timestamp the

cache can compare. Since retrieving the last modification time is an

expensive operation in the case of a webdav source determining the

validity of a cached response would be almost as expensive as generating

a new response, requiring a webdav propfind for each source that is a

member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the

Cache that the source is always valid using a special Validity object.

Cache invalidation will be accomplished by an external event triggering

the removal of all pipelines the Source is associated with. This means

though that a subsequent request will be slow since nothing is cached

anymore.

Perhaps even more importantly, since the pipelines can be huge objects

the generation of which potentially requires many network calls it is

much better to cache objects at the most atomic level: the source. Hence

my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so that

an external event (say, someone saving a document in the webdav

repository) will trigger the retrieval of a fresh one. But in the

background, away from the critical path (asynchronous).

Hope that explains it better.

Unico


CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

 

RE: JCS Based Cache

[Corin Moss]

Ok then,

The JCS based store is pretty much finished (well, obviously the first cut.)  As far 
as I can tell I've implemented everything necessary for a test - there's a few un-used 
methods not implemented (I've commented these fairly clearly of course ;)

What's the protocol for sharing the source?  Should I just email it to the list?  I've 
obviously not had time to do any decent testing so far, but I'll run load tests on it 
now before I head home :) 

This really was a breeze - it's as if the Avalon store was built with JCS in mind :)

Anyway, let me know how I should best supply the code and I'll send it tomorrow 
morning NZ time when I get in.

Thanks guys,

Corin

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 2 March 2004 10:02 p.m.
To: [EMAIL PROTECTED]
Subject: Re: JCS Based Cache


Le Mardi, 2 mars 2004, à 09:52 Europe/Zurich, Sylvain Wallez a écrit :
> ...Have a look in cocoon.roles: it's the default class for the
> "org.apache.excalibur.store.Store/PersistentStore" role.

I did
$ find src -type f | xargs grep -i defaultpersistent

and it told me indeed:
src/java/org/apache/cocoon/cocoon.roles:
   
default-
class="org.apache.cocoon.components.store.impl.DefaultPersistentStore"/ >

so
> Hey Bertrand, still asleep?
I guess yes ;-)

sorry for the noise.
-Bertrand



CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.


For more information on the Television New Zealand Group, visit
us online at http://www.tvnz.co.nz

FlowScript in 2.1.5-dev has gone tango uniform

[Jeremy Quinn]

Hi All

I just upgraded my copy of Cocoon to today's CVS version.

A (previously working) site that uses a lot of FlowScript has gone 
completely TU.

I am getting a lot of this :

org.apache.cocoon.ResourceNotFoundException: Function 
"javascript:album()" not found

Where it worked before the update.

But stranger still, while I was doing some testing, I got an error that 
said that a script that was not even referred to by the current 
pipeline, did not contain the function I was calling !!

Do what ?!?

Have there been some changes to the FlowScript infrastructure that 
could result in the wrong FlowScript file being used under certain 
circumstances?

I have several flowscripts, used independently by different 
Sub-SiteMaps, that have the same function names. The first SiteMap I 
invoke, works (does not matter which one) all subsequent invocations of 
pipelines with similar (but different) FlowScripts fail.

Any ideas anyone?

regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature

Re: JCS Based Cache

[Geoff Howard]

Corin Moss wrote:

Ok then,

The JCS based store is pretty much finished (well, obviously the first cut.)  As far as I can tell I've implemented everything necessary for a test - there's a few un-used methods not implemented (I've commented these fairly clearly of course ;)

What's the protocol for sharing the source?  Should I just email it to the list?  I've obviously not had time to do any decent testing so far, but I'll run load tests on it now before I head home :) 

This really was a breeze - it's as if the Avalon store was built with JCS in mind :)

Anyway, let me know how I should best supply the code and I'll send it tomorrow morning NZ time when I get in.
 

I think we say the preferable way would be to create a bugzilla "patch" 
entry, which for new features is just a "bug" whose description starts 
with [PATCH] and has the source attached, usually as a .zip file.  A 
unified diff of the cocoon.xconf or cocoon.roles file needed to use this 
component impl might make it easier to apply and test, but probably not 
necessary.

Geoff

-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 2 March 2004 10:02 p.m.
To: [EMAIL PROTECTED]
Subject: Re: JCS Based Cache
Le Mardi, 2 mars 2004, à 09:52 Europe/Zurich, Sylvain Wallez a écrit :
 

...Have a look in cocoon.roles: it's the default class for the
"org.apache.excalibur.store.Store/PersistentStore" role.
   

I did
$ find src -type f | xargs grep -i defaultpersistent
and it told me indeed:
src/java/org/apache/cocoon/cocoon.roles:
  

default-

class="org.apache.cocoon.components.store.impl.DefaultPersistentStore"/ >

so
 

Hey Bertrand, still asleep?
   

I guess yes ;-)

sorry for the noise.
-Bertrand
 

Re: Event caching and CachedSource

[Geoff Howard]

Unico Hommes wrote:

Geoff Howard wrote:

Unico Hommes wrote:

Corin Moss wrote:

Hiya,

I'm probably wrong here, but my understanding of the RefresherImpl is
that the "timeout" is used to cache the page on a timed basis a la 
cron
(although that could be what you mean).

I'm not entirely sure how this helps with external validation directly
:)
What I've been playing around with in this class is a 
"refreshInFuture"
method which does a one-time-only refresh in x seconds (probably 1
minimum to be safe from expiry problems :)

Does that help you at all? I'm happy to contribute it if it would.

 

Hmm, I guess my explanation was a little bit dense. Let me put this 
into context of the things I am trying to solve.

We recently deployed a website that is backed by a webdav 
repository. Obviously this introduces some network overhead and 
particular parts of the site can get slow to generate. Especially 
those generated using TraversableGenerators.

Traditional caching requires the objects on behalf of which it 
caches to provide a so called Validity object in order to determine 
whether its cached objects are still valid upon subsequent request. 
Most sources will try to determine this by providing a last modifed 
timestamp the cache can compare. Since retrieving the last 
modification time is an expensive operation in the case of a webdav 
source determining the validity of a cached response would be almost 
as expensive as generating a new response, requiring a webdav 
propfind for each source that is a member of the generated pipeline.

Instead we employ a different strategy altoghether. We just tell the 
Cache that the source is always valid using a special Validity 
object. Cache invalidation will be accomplished by an external event 
triggering the removal of all pipelines the Source is associated 
with. This means though that a subsequent request will be slow since 
nothing is cached anymore.

Perhaps even more importantly, since the pipelines can be huge 
objects the generation of which potentially requires many network 
calls it is much better to cache objects at the most atomic level: 
the source. Hence my interest in CachedSource.

What I am proposing is to extend the capability of CachedSource so 
that an external event (say, someone saving a document in the webdav 
repository) will trigger the retrieval of a fresh one. But in the 
background, away from the critical path (asynchronous).

Hope that explains it better.


Ok, I'm done being dense - I get this now. 


Sorry it wasn't meant to suggest you or anybody was being dense. Just 
that my explanation was overly concise.;-)


No, I saw where you placed blame (on your explanation) -- I just 
disagreed with your diagnosis.  :)  In my case, it was the "explainee" 
not the explanation that was the problem!

My last response about pluggable cache strategies at the pipeline 
level is totally mismatched.  At the Source level you don't have to 
worry about re-assembling the pipeline, so all you would have to do 
is re-cache the source when it is invalidated externally.


Exactly.

Can you just handle this when the JMS/other event comes in?  
Currently it's just translated to an Event and sent to the Cache, but 
you could also contact the Source as well at that point?  Where does 
the Source cache its data?  In memory in a private member, or in the 
Store?


You got it! (in the Cache/Store)


Whew!  Ok, I can't give this much more thought ATM, but sounds like a 
good direction to me, for what that's worth.

Geoff

Re: Momento and Cocoon

[Alan]

* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 14:04]:
> Alan wrote:
> 
> >* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 06:07]:
> 
> >>I need a fast and scalable xquery-capable semi-structured content 
> >>repository.
> >>
> >>Can momento provide me that?
> >
> >
> >It could. If I were to release it open source. That's the point.
> >That's why I'm engaging people on this list.
> >
> 
> It could seems like a pretty big overestimation without reasonable 
> technological backup.

> At least three research groups spent 10 years and millions of dollars 
> trying to build an equivalent system. One of them died (Lore) [but the 
> source code disappeared so I suspect some big DBMS vendor bought the 
> thing], the other went commercial [Xyleme], the other is still 
> researching [the people at Bell Labs]

What about Berkeley XML-DB? It seems to be a popular open source
database. There is also dbXML, which is now GPL. What about
Xindice?

I'm not sure what you are expecting. Momento is XQuery capable
and the content is semi-structured. That took a couple months,
but nothing like a million dollars.

Fast and scalable? Sure. Why not? If there was a design flaw
that would prevent concurrent queries or updates, I'm sure it
would have surfaced by now.


> Don't get me wrong: I know the power of open source and I know that you 
> need to start somewhere, that's why I'm asking.

Yes. You need to start somewhere. 

I'm starting out with the organization of the document into
clusters based on application requirements.

Michael Kay and I are discussing how to add a simple identity
key for use with the id attribute and the key element in XSLT.

I'm not going to start with benchmark peformance tests.


> What I don't understand is how you can use Saxon as a fast and scalable 
> database since it wasn't designed to do so.

I am using Saxon as a query engine. Momento is a document object model.

Again, I'm not sure what you are expecting. I'm trying not to
get you wrong.


-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

Re: JCS Based Cache

[Bertrand Delacretaz]

Le Mardi, 2 mars 2004, à 15:30 Europe/Zurich, Geoff Howard a écrit :

...I think we say the preferable way would be to create a bugzilla 
"patch" entry, which for new features is just a "bug" whose 
description starts with [PATCH] and has the source attached, usually 
as a .zip file.  A unified diff of the cocoon.xconf or cocoon.roles 
file needed to use this component impl might make it easier to apply 
and test, but probably not necessary.
See http://cocoon.apache.org/2.1/howto/howto-patch.html for how to 
prepare patches.

-Bertrand, perfectly awaken by now ;-)

Re: workflow block commited

[Andrew Savory]

Hi,

On 1 Mar 2004, at 18:25, Arje Cahn wrote:

I'm interested in a workflow block as well. We currently have 
experience using OpenSymphony Workflow and would like to share this on 
the Cocoon list.
I'm excited to see the workflow block appearing (yes, I need to get a 
life!). Arje, have you any experience of the Codehaus Werkflow [1] 
approach? I'd be interested to know how it compares with OpenSymphony.

How does the lenya workflow block cope with existing workflow standards 
such as BPEL[2] or XPDL [3]?

[1] http://werkflow.codehaus.org/
[2] http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
[3] http://purl.oclc.org/NET/xpdl
Thanks,

Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

RE: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/ cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl. java

[Hunsberger, Peter]

Geoff Howard <[EMAIL PROTECTED]> writes:


 
> >
> >Maybe we should consider marking the block "stable"?
> >  
> >
> >
> >+1 That would be good from our perspective.  If it made it 
> into 2.1.6 
> >+as
> >stable we'd be more comfortable depending on it.
> >  
> >
> 
> :)  Sounds like another chicken and egg.  Murphy's law says 
> that if we 
> mark it a stable API and you test it this summer, you'll need the API 
> changed...
 
Chuckle,  well we do still have the issue of how to chase down entire
dependency trees  At the moment we take a brute force approach; if
you touch any part of the tree the whole tree gets invalidated.  Part of
the scheduled initiative will be to add caching for the data that we
don't currently cache.  At that point, the brute force approach just
won't cut it since we'll have intersecting trees and touching just about
anything will result in cascades of invalidation...

Java chokes on logkit-1.2.2

[Vadim Gritsenko]

Java:
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
Starting tomcat fails with:
javaw.exe  -Xms64m -Xmx64m -Dcatalina.home=C:\Java\jakarta-tomcat-4.1.24 
-classpath C:\Java\jakarta-tomcat-4.1.24\bin\bootstrap.jar -Xdebug 
-Xnoagent -Djava.compiler=NONE 
-Xrunjdwp:transport=dt_socket,address=ANIMAL:2351,suspend=y,server=n 
org.apache.catalina.startup.Bootstrap start
02.03.2004 9:44:56 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/4.1.24
Catalina.start: LifecycleException:  start: :  
java.lang.IllegalArgumentException: 
avalon-framework,log4j,commons-logging,servletapi,javamail,jms,junit-Extension-Name
LifecycleException:  start: :  java.lang.IllegalArgumentException: 
avalon-framework,log4j,commons-logging,servletapi,javamail,jms,junit-Extension-Name
   at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:678)
   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3530)
...
- Root Cause -
java.lang.IllegalArgumentException: 
avalon-framework,log4j,commons-logging,servletapi,javamail,jms,junit-Extension-Name
   at java.util.jar.Attributes$Name.(Attributes.java:434)
   at java.util.jar.Attributes.getValue(Attributes.java:97)
   at org.apache.catalina.loader.Extension.getRequired(Extension.java:415)
   at org.apache.catalina.loader.Extension.getRequired(Extension.java:338)
   at 
org.apache.catalina.loader.WebappClassLoader.addJar(WebappClassLoader.java:706)
   at 
org.apache.catalina.loader.WebappLoader.setRepositories(WebappLoader.java:1067)
   at org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:665)
...

After removing manifest, following exception is thrown:
Logging Error: Could not set up Cocoon Logger, will use screen instead
org.apache.avalon.framework.configuration.ConfigurationException: No log 
targets configured for the root logger.
   at 
org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupLoggers(LogKitLoggerManager.java:531)
   at 
org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure(LogKitLoggerManager.java:407)
   at 
org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:853)
   at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:338)
   at gov.dc.octo.hsmp.servlet.CocoonServlet.init(CocoonServlet.java:57)
...

So, what happened with logkit?

Vadim

RE: Gump

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:



> I have a RT ready for gump that would allow to solve these 
> issues... but 
> I need to work more on this since it appears to be a pretty tough 
> computational problem of graph analysis.

We do have generalized hedge generator code (both in a Cocoon sense and
in a flat query to data structure sense) that I might be able to get you
a copy of ;-)...  However, I suspect you need the opposite of what we
have; something to break down tree structured data into hedges and look
for intersections (cycles)?

RE: Java chokes on logkit-1.2.2

[Carsten Ziegeler]

Did you try a clean build?

I have the same jdk and for me it works perfectly :)
The second exception you get is due to a change in excalibur-logger.
The logkit.xconf needs an entry for the root category (category
without a name). I have fixed this some days ago in the CVS.

Carsten 

> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 02, 2004 4:01 PM
> To: Cocoon Developers
> Subject: Java chokes on logkit-1.2.2
> 
> Java:
> java version "1.4.2"
> Java(TM) 2 Runtime Environment, Standard Edition (build 
> 1.4.2-b28) Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
> 
> Starting tomcat fails with:
> javaw.exe  -Xms64m -Xmx64m 
> -Dcatalina.home=C:\Java\jakarta-tomcat-4.1.24
> -classpath C:\Java\jakarta-tomcat-4.1.24\bin\bootstrap.jar 
> -Xdebug -Xnoagent -Djava.compiler=NONE 
> -Xrunjdwp:transport=dt_socket,address=ANIMAL:2351,suspend=y,server=n
> org.apache.catalina.startup.Bootstrap start
> 02.03.2004 9:44:56 org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on port 8080 Starting 
> service Tomcat-Standalone Apache Tomcat/4.1.24
> Catalina.start: LifecycleException:  start: :  
> java.lang.IllegalArgumentException: 
> avalon-framework,log4j,commons-logging,servletapi,javamail,jms
> ,junit-Extension-Name
> LifecycleException:  start: :  java.lang.IllegalArgumentException: 
> avalon-framework,log4j,commons-logging,servletapi,javamail,jms
> ,junit-Extension-Name
> at 
> org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:678)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext
> .java:3530)
> ...
> - Root Cause -
> java.lang.IllegalArgumentException: 
> avalon-framework,log4j,commons-logging,servletapi,javamail,jms
> ,junit-Extension-Name
> at java.util.jar.Attributes$Name.(Attributes.java:434)
> at java.util.jar.Attributes.getValue(Attributes.java:97)
> at 
> org.apache.catalina.loader.Extension.getRequired(Extension.java:415)
> at 
> org.apache.catalina.loader.Extension.getRequired(Extension.java:338)
> at
> org.apache.catalina.loader.WebappClassLoader.addJar(WebappClas
> sLoader.java:706)
> at
> org.apache.catalina.loader.WebappLoader.setRepositories(Webapp
> Loader.java:1067)
> at 
> org.apache.catalina.loader.WebappLoader.start(WebappLoader.java:665)
> ...
> 
> 
> After removing manifest, following exception is thrown:
> Logging Error: Could not set up Cocoon Logger, will use screen instead
> org.apache.avalon.framework.configuration.ConfigurationExcepti
> on: No log targets configured for the root logger.
> at
> org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupLo
> ggers(LogKitLoggerManager.java:531)
> at
> org.apache.avalon.excalibur.logger.LogKitLoggerManager.configu
> re(LogKitLoggerManager.java:407)
> at
> org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServl
> et.java:853)
> at 
> org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:338)
> at 
> gov.dc.octo.hsmp.servlet.CocoonServlet.init(CocoonServlet.java:57)
> ...
> 
> 
> So, what happened with logkit?
> 
> Vadim
> 

RE: Event caching and CachedSource

[Hunsberger, Peter]

Unico Hommes <[EMAIL PROTECTED]> writes:

> 
> Hi gang :-)
> 
> A drawback I have been running into lately with eventcache 
> mechanism is 
> that it lacks the ability to remove heavy processing from the 
> critical 
> path. An event will simply remove a set of cached pipelines from the 
> cache completely. Making the subsequent request for such a pipeline 
> potentialy very slow. In applications where isolation is not a 
> requirement this is an unnecessary drawback.
> 
> I am looking at the excellent CachedSource stuff that is in the 
> scratchpad area ATM and am wondering how it fits together with the 
> eventcache stuff. One thing I am looking into right now is to 
> write an 
> EventAware Refresher implementation.

Cool, in our case, for much of our data, we know we can, in theory,
repopulate the cache the moment after the data is invalidated (which is
the moment before the new version is committed).  However, we need to do
this asynchronously if possible.  We haven't started to look at this
issue, but it sounds like this might be the way to go?

> 
> For those unfamiliar with CachedSource, it is a Source 
> wrapper that can 
> cache a its delegate. Refreshing can be done either synchronously or 
> asynchronously but currently only based upon a specified 
> time-out. What 
> I'd like to do is generalize this a bit in order to add the 
> ability to  
> externally trigger invalidation.
>

Re: Java chokes on logkit-1.2.2

[Vadim Gritsenko]

Carsten Ziegeler wrote:

Did you try a clean build?
 

It's not a cocoon cvs; it's copy of cocoon libs into web-inf/lib.


I have the same jdk and for me it works perfectly :)
The second exception you get is due to a change in excalibur-logger.
The logkit.xconf needs an entry for the root category (category
without a name). I have fixed this some days ago in the CVS.
 

Ah! Did not expect migration issues from 2.1.4 to 2.1.5-dev. Ok, thanks.

Vadim

Re: FlowScript in 2.1.5-dev has gone tango uniform

[Christopher Oliver]

Can you try reverting the rhino jar to a previous version and see if 
that fixes the problem? I may have introduced a regression.

Thanks,

Chris

Jeremy Quinn wrote:

Hi All

I just upgraded my copy of Cocoon to today's CVS version.

A (previously working) site that uses a lot of FlowScript has gone 
completely TU.

I am getting a lot of this :

org.apache.cocoon.ResourceNotFoundException: Function 
"javascript:album()" not found

Where it worked before the update.

But stranger still, while I was doing some testing, I got an error 
that said that a script that was not even referred to by the current 
pipeline, did not contain the function I was calling !!

Do what ?!?

Have there been some changes to the FlowScript infrastructure that 
could result in the wrong FlowScript file being used under certain 
circumstances?

I have several flowscripts, used independently by different 
Sub-SiteMaps, that have the same function names. The first SiteMap I 
invoke, works (does not matter which one) all subsequent invocations 
of pipelines with similar (but different) FlowScripts fail.

Any ideas anyone?

regards Jeremy

Re: JCS Based Cache

[Upayavira]

Corin Moss wrote:

Ok then,

The JCS based store is pretty much finished (well, obviously the first cut.)  As far as I can tell I've implemented everything necessary for a test - there's a few un-used methods not implemented (I've commented these fairly clearly of course ;)

What's the protocol for sharing the source?  Should I just email it to the list?  I've obviously not had time to do any decent testing so far, but I'll run load tests on it now before I head home :) 
 

Look forwards to the results. Will you run the same tests on the Jisp 
based store too?

This really was a breeze - it's as if the Avalon store was built with JCS in mind :)
 

Great.

Anyway, let me know how I should best supply the code and I'll send it tomorrow morning NZ time when I get in.
 

A patch submitted to bugzilla.

Thanks guys,
 

And thanks to you.

Upayavira

Re: [RT] Cocoon Input Model

[Alan]

* Hunsberger, Peter <[EMAIL PROTECTED]> [2004-03-01 22:06]:
> Alan <[EMAIL PROTECTED]> writes:
> 
> 
> 
> > > > There is already flow logic in the site map. The pipeline is a
> > > > select statement. It is a clear expression of the pipelines
> > > > intent.
> > 
> > > Ok, that's where we differ.  Our pipeline does not implement a
> > > select statement.  You can't, in general, look at our
> > > pipelines and determine what will come out of them.  Even
> > > prior to implementing flowscript all you could tell was that a
> > > certain sequence of generators and transformers would be
> > > called (I guess that's what you call "pipeline intent").

> > > However, once you have flow I don't see what that buys you?

> > > We can still determine that, but instead of starting at the
> > > sitemap we start at the flowscript: all flow starts from the
> > > same point in the sitemap: "*/**" --> call function(main).
> > > Half a dozen special case pages branch somewhere specific in
> > > our flowscript, the rest end back at the same point in the
> > > sitemap: "_page/*" --> generate --> transform --> serialize.
> > > Really, very easy to understand.  (BTW, when we implemented
> > > flow our sitemap shrank in size by half or more.)
> > 
> > Okay, I think I can see that model.
> > 
> > I put a lot of information into the URI. It makes for
> > permalinks. An application can be expressed in the sitemap
> > matching.



> > I'm putting a lot of my logic in my XSLT transforms, I guess. I like
> > to have it all my logic in one place. I like that each step
> > along the way produces a document, which can be viewed in the
> > browser as XML. I like the declaritive nature of the pipeline
> > content.
>  
> I suspected you might be an XSLT heavy :-)  If you do a search of the
> dev archives you'll see I argued for a long time to be able to write the
> flow engine in XSLT...  I'd still like to do that; we've got a work flow
> project on the books that will require the same kind of generic rule
> based business logic for work flow that we do for data handling.  It
> would be nice to hook it into the same generic rule handling we
> currently have.

> > I am using the matching facilities agressively. It is how I see a
> > web application. A GET are function calls, the URI's are the
> > function signatures, the pipelines are the function bodies. Its
> > stateless functional programming to me.
> 
> Well, yes, but you're encoding application logic in the sitemap.  That
> just doesn't scale;  the sitemap isn't supposed to be a programming
> language.  REST is fine, but flow isn't anti-REST (RESTless ?)...

It's a pity that it doesn't scale then, because it's been a nice way
to do things.

I'm not putting much logic in the sitemap except to
match the path part of the URI. Parameter handling is done by
whoever intercepts the path. Most of my logic is in XSLT.

I came to Cocoon from XSLT. I was already chaining
trasformations. I'd made the most of a little matching engine
I'd written. I'm using Cocoon thus.

Flow isn't anti-REST, but, yeah, the sitemap looks like a REST
method dispatch engine.

Maybe that is what I want. Maybe its easy to do this in flow,
and if I want to be declartive, my flowscript can read a
configuration file.

> > The way I've implemented POST in the pass is to go forward or to
> > return the post data with error messages. A single form contains
> > data for single post. I rarely see a need to branch after success.
> > 
> > Flow doesn't play a part in who I *intend* to use Cocoon. I'm
> > not that far into it yet.
> 
> Well, I guess I'm telling you that you should maybe think about changing
> your direction

I see that. I am thinking about changing direction.

Two things.

1) I jumped into this because it was a discussion of input
   pipelines and I was interested in it in terms of Momento.
   
   I know there is some use of XUpdate in Cocoon, but that is
   the preferred language for Momento. I see the penultimate
   step in an input pipeline as a transform to XUpdate, the
   ultimate step a call to Momento.
   
   I think if someone were to develop a simpiliar declartive
   language to describe a complex set of SQL updates in XML, one
   cold use the same notion to update an SQL database. This,
   rather than writing loops, JDBC calls, and such in Java.

2) I see that this is more of a disucssion of the
   deserialization and form validation. I will be able to do the
   above. Nothing is going to move out from underneith those
   plans while I'm implementing them. 

Also, thanks for all the knowledge.

-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

Re: Event caching and CachedSource

[Unico Hommes]

Carsten Ziegeler wrote:

Unico Hommes wrote:
 

Hi gang :-)

A drawback I have been running into lately with eventcache 
mechanism is that it lacks the ability to remove heavy 
processing from the critical path. An event will simply 
remove a set of cached pipelines from the cache completely. 
Making the subsequent request for such a pipeline potentialy 
very slow. In applications where isolation is not a 
requirement this is an unnecessary drawback.

I am looking at the excellent CachedSource stuff that is in 
the scratchpad area ATM and am wondering how it fits together 
with the eventcache stuff. One thing I am looking into right 
now is to write an EventAware Refresher implementation.

For those unfamiliar with CachedSource, it is a Source 
wrapper that can cache a its delegate. Refreshing can be done 
either synchronously or asynchronously but currently only 
based upon a specified time-out. What I'd like to do is 
generalize this a bit in order to add the ability to 
externally trigger invalidation.

For this however I think a modification to the Refresher 
interface is needed.

Instead of:

Refresher {
 refresh(key,uri,timeout);
 periodicallyRefresh(key,uri,timeout);
}
I'd like to remove timeout semantics from the interface:

Refresher {
 refresh(key,uri,params);
}
I don't think there is currently a reason for there being two 
the separate methods. So I think we can safely combine them 
into one. But I guess I am looking at Carsten for confirmation... :-)

   

Although you actually don't need my confirmation as it's not my
but *our* source, here it is :)
I think this makes sense and I think we should also move this
out of the scratchpad afterwards as well.
 

I'd also like to change the protocol URL a little bit. Since the timeout 
parameter will only be applicable to the delay refresher implementation 
and not to the event aware one I think it would be better to specify it 
with a query parameter instead.

Current syntax: cache://[EMAIL PROTECTED]@http://www.apache.org/
Proposed syntax: 
cache:http://www.apache.org/?cache-expires=60&cache-name=main

The protocol:subprotocol syntax is also more in line with well 
established conventions such as in jdbc for instance.

Let me know if you have any objections or comments.

Unico

RE: patch to Enhance CIncludeTrasnformer to handle encodingofparameters

[Bruno Dumon]

On Tue, 2004-03-02 at 14:57, Marco Dubbeld wrote:
> On Tue, 2004-03-02 at 13:29, Carsten Ziegeler wrote:
> > Marco Dubbeld wrote:
> > > 
> > > Yep! The value element may contain UTF-8, with chinese 
> > > characters or other non ISO-8859 encoding characters. While 
> > > testing, the 
> > > 
> > > this.startSerializedXMLRecording(XMLUtils.defaultSerializeToXM
> > > LFormat(true));
> > > will use ISO-8859 encoding (see the properties given back 
> > > from XMLUtils). However we should use a property set with the 
> > > encoding from the document we are transforming. Otherwise 
> > > this causes UTFDataFormatException for chinese UTF-8 for example.
> > 
> > So the best way would be to pass the encoding of the document
> > to the XMLUtils used for serializing. Is this possible?
> Properties props = XMLUtils.defaultSerializeToXMLFormat(true);
> String encoding = ??
> props.set(OutputKeys.ENCODING, encoding);
> this.startSerializedXMLRecording(props);
> 
> How to determine most properly the encoding of the events or the input
> source I do not precisly know.
> java.sun.com is down from my location so one half of my brains is
> blocked. If it's back I try to search. 
> 
> Maybe someone on the list knows ?

You just need to choose something. I don't think SAX provides
information about the encoding of the original document. Always using
UTF-8 should be a safe choice.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[Portal] Why don't cocoon errors appear in a coplet ?

[Olivier Billard]

Hi cocooners !

I posted in the users' but maybe some sitemap gurus can show me the light ;).

I use the portal for a project and i'm not able to display errors in a (main) coplet.
I always have a blank content, as if when rendering the content of the coplet, the error 
content is not put in the whole portal page.

I tried xml-serializing, html-serializing errors :


  

  
  


  
  


  
  

  
  


  
  

  
  
--->  

  


(map:otherwise is choosen, i tried renaming the transformer src attribute)

But no way : I have no content in the coplet...
I can right display the error when calling the coplet pipe, but it' empty in the portal 
page...

It seems to work like standard/error output : when an error occurs, the standard sitemap 
output is empty, and the sitemap error output contains the error catched in the 
map:handle-errors.

Thanks in advance for your answers !

--
Olivier BILLARD

RE: [RT] Cocoon Input Model

[Hunsberger, Peter]

Alan <[EMAIL PROTECTED]> writes:
 


> 
> > > I am using the matching facilities agressively. It is how I see a
> > > web application. A GET are function calls, the URI's are the
> > > function signatures, the pipelines are the function 
> bodies. Its
> > > stateless functional programming to me.
> > 
> > Well, yes, but you're encoding application logic in the 
> sitemap.  That 
> > just doesn't scale;  the sitemap isn't supposed to be a programming 
> > language.  REST is fine, but flow isn't anti-REST (RESTless ?)...
> 
> It's a pity that it doesn't scale then, because it's been a nice way
> to do things.
> 
> I'm not putting much logic in the sitemap except to
> match the path part of the URI. Parameter handling is done by
> whoever intercepts the path. Most of my logic is in XSLT.
> 
> I came to Cocoon from XSLT. I was already chaining
> trasformations. I'd made the most of a little matching engine
> I'd written. I'm using Cocoon thus.
> 
> Flow isn't anti-REST, but, yeah, the sitemap looks like a REST
> method dispatch engine.
> 
> Maybe that is what I want. Maybe its easy to do this in flow,
> and if I want to be declartive, my flowscript can read a
> configuration file.

I suspect that once you start to parameterize and generalize this you'll
find that flow doesn't need to read much in the way of a configuration
file...  However, if it does, I'll suggest that this configuration is
itself stored in your "database" and treated the same way as any of your
other data (although it's technically metadata).



> 
> Two things.
> 
> 1) I jumped into this because it was a discussion of input
>pipelines and I was interested in it in terms of Momento.
>
>I know there is some use of XUpdate in Cocoon, but that is
>the preferred language for Momento. I see the penultimate
>step in an input pipeline as a transform to XUpdate, the
>ultimate step a call to Momento.
>
>I think if someone were to develop a simpiliar declartive
>language to describe a complex set of SQL updates in XML, one
>cold use the same notion to update an SQL database. This,
>rather than writing loops, JDBC calls, and such in Java.

Probably a good thing, though one we're a long way from.  

We've got a relational DB with an abstract object model underneath
everything we do.  The entire system (front and back end) is described
in metadata.  The interface to Cocoon from the back end is via proxied
EJB's.  Cocoon has about a dozen generators hitting these proxies and
they in turn feed about a dozen XSLT's.  Nothing involved directly with
the UI knows anything other than the object model, although a layer of
XSLT have the responsibility of assembling instances of the object model
from the metadata, screen specific templates, security information and
the actual data.  In theory, we can remove the HTML producing XSLT and
slap on, say, a set of PDF producing XSLT and change nothing else in the
system...

> 2) I see that this is more of a disucssion of the
>deserialization and form validation. I will be able to do the
>above. Nothing is going to move out from underneith those
>plans while I'm implementing them. 

Agreed!

> 
> Also, thanks for all the knowledge.
 
Anytime...

Re: Momento and Cocoon

[Stefano Mazzocchi]

Alan wrote:

* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 14:04]:

Alan wrote:


* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 06:07]:

I need a fast and scalable xquery-capable semi-structured content 
repository.

Can momento provide me that?


  It could. If I were to release it open source. That's the point.
  That's why I'm engaging people on this list.
It could seems like a pretty big overestimation without reasonable 
technological backup.


At least three research groups spent 10 years and millions of dollars 
trying to build an equivalent system. One of them died (Lore) [but the 
source code disappeared so I suspect some big DBMS vendor bought the 
thing], the other went commercial [Xyleme], the other is still 
researching [the people at Bell Labs]


What about Berkeley XML-DB? 
doesn't support xquery, its license is incompatible with the ours, it 
doesn't scale on multiple machines and the java API is pathetic.

It seems to be a popular open source database. There is also dbXML, which is now GPL. 
What about
Xindice?
doesn't support xquery, hasn't been tested in heavy duty environments,

I'm not sure what you are expecting. Momento is XQuery capable
and the content is semi-structured. That took a couple months,
but nothing like a million dollars.

Fast and scalable? Sure. Why not? If there was a design flaw
that would prevent concurrent queries or updates, I'm sure it
would have surfaced by now.
Hmmm, how much data did you have in there?

Don't get me wrong: I know the power of open source and I know that you 
need to start somewhere, that's why I'm asking.


Yes. You need to start somewhere.  
yep.

I'm starting out with the organization of the document into
clusters based on application requirements.
Like xindice collections?

Michael Kay and I are discussing how to add a simple identity
key for use with the id attribute and the key element in XSLT.
I'm not going to start with benchmark peformance tests.
Good, if you need tons of xml to test the system let me know.

What I don't understand is how you can use Saxon as a fast and scalable 
database since it wasn't designed to do so.


I am using Saxon as a query engine. Momento is a document object model.

Again, I'm not sure what you are expecting. I'm trying not to
get you wrong.
I need an xml database with xquery capabilities to place as a slide 
store for when it will implement JCR.

Xindice is currently my candidate for that, but I'm always open for 
potential alternatives.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Momento and Cocoon

[Alan]

* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 17:34]:
> Alan wrote:
> 
> >* Stefano Mazzocchi <[EMAIL PROTECTED]> [2004-03-02 14:04]:

> I need an xml database with xquery capabilities to place as a
> slide store for when it will implement JCR.

???

> Xindice is currently my candidate for that, but I'm always open
> for potential alternatives.


By all means use Xindice. Momento is still underdevelopment. It is
not yet ready for production use.

If you want to know more about the design, or the status there
is more information about Momento at my web site.

Cheers.

-- 
Alan / [EMAIL PROTECTED] / http://engrm.com/
aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]

RE: Gump

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]>:

> 
> Hunsberger, Peter wrote:
> 
> > Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
> > 
> > 
> > 
> >>I have a RT ready for gump that would allow to solve these
> >>issues... but 
> >>I need to work more on this since it appears to be a pretty tough 
> >>computational problem of graph analysis.
> > 
> > 
> > We do have generalized hedge generator code (both in a Cocoon sense 
> > and in a flat query to data structure sense) that I might 
> be able to 
> > get you a copy of ;-)...  However, I suspect you need the 
> opposite of 
> > what we have; something to break down tree structured data 
> into hedges 
> > and look for intersections (cycles)?
> 
> oh, nono, the problem is completely different: when a project doesn't 
> compile, who's fault is that?
> 
> Currently gump has information such as
> 
>   (A) --(depends on)--> (B)
> 
> the problem with this is that if A breaks, it could be because of B's 
> fault or because of A's fault, you can't tell.
> 
> What I'm going to propose is to have bidimensional dependencies:
> 
>   (A,20040302) --(depends on)--> (B,20040212)
> 
> At this point, gump can do multiple builds based on the 
> timestamp and it 
> is possible figure out who broke what and when, in theory 
> point at the 
> very single commit to blame.
> 
> The problem is that the complexity of such trellis grows very 
> big very 
> quickly. I still have to understand if it's duable at all!

Hmm, so, for any random initial state it is possible that: 

A -(depends on)-> C  
B -(depends on)-> C

And that a single change to C fixes A but breaks B, thus, you add the
timestamp...

If so, it's still the same problem, just more data (which is perhaps the
entire issue?): find all the (perhaps arbitrary) tree roots that either
give a good build or are the most recent version of the code for which a
breakage still exists.  If you've got a good build you can prune all
prior timestamps.  If you always have breakage you can prune all prior
timestamps. (In the above example, you'd need to retain two versions,
but no more, if everything else dependant on C built properly with
either version.)  

However, even with the pruned tree I'm not sure if the problem is
solvable in general: IIUC there is no known general algorithm for cyclic
graph traversal that can be guaranteed to terminate (for any random
graph)?  If however, you can force a known initial state (always start
from the same spot on the graph) then perhaps things are a little more
hopeful?  Not sure, I think you're on your own on this one...

Re: FlowScript in 2.1.5-dev has gone tango uniform

[Jeremy Quinn]

On 2 Mar 2004, at 15:22, Christopher Oliver wrote:

Can you try reverting the rhino jar to a previous version and see if 
that fixes the problem? I may have introduced a regression.
Many thanks for your reply.

I picked up :

rhino1.5r4-continuations-20040218.jar
  and
rhino1.5r4-continuations-20030906.jar
from CVS and one by one replaced rhino1.5r4-continuations-20040228.jar 
with them, in build/webapps/WEB-INF/lib, it made no difference.

then I tried recompiling 2.1.5-dev with 
rhino1.5r4-continuations-20030906.jar (in lib/core, and jar.xml). The 
problem is still not fixed.

To restate the basic problem :

I have 2 URLs each served by a different sub-sitemap, each loading a 
different (single) flowscript. Each flowscript has some common function 
names, eg. index(). For debugging purposes, each function outputs it's 
name etc. to the flow log.

load URL 1 : the correct script and function run fine
load URL 2 : the same-named function in the flowscript file for URL 1 
runs.

regards Jeremy

Jeremy Quinn wrote:

Hi All

I just upgraded my copy of Cocoon to today's CVS version.

A (previously working) site that uses a lot of FlowScript has gone 
completely TU.

I am getting a lot of this :

org.apache.cocoon.ResourceNotFoundException: Function 
"javascript:album()" not found

Where it worked before the update.

But stranger still, while I was doing some testing, I got an error 
that said that a script that was not even referred to by the current 
pipeline, did not contain the function I was calling !!

Do what ?!?

Have there been some changes to the FlowScript infrastructure that 
could result in the wrong FlowScript file being used under certain 
circumstances?

I have several flowscripts, used independently by different 
Sub-SiteMaps, that have the same function names. The first SiteMap I 
invoke, works (does not matter which one) all subsequent invocations 
of pipelines with similar (but different) FlowScripts fail.

Any ideas anyone?

regards Jeremy




smime.p7s
Description: S/MIME cryptographic signature

[CForms] Support for multipe unique-row-id in Repeater

[Antonio Gallardo]

OK.

It is done! Now we can write:

 
   
 
 
   
   
 
 
 
 
   
 

NOTE: The "old style" is also supported. You don't need to rewrite your
code. But I think we can also deprecate the old way (using attributes).

For more info see the initial mails below

Best Regards,

Antonio Gallardo

Antonio Gallardo dijo:
> Hi Tim:
>
> Thanks for the description. Now I see to TempRepeater as a
> SimpleRpeater++. Is this correct?
>
> I am looking for a similar repeater some days ago. The problem is:
>
> I have a table with a Primary Key with more than one field. The current
> repeaters does not allow me to define a unique-id with more that one
> field. And in my case:
>
> rowNumber  id1 id2
> 11  1
> 21  2
> 32  1
> 42  2
> 
>
> In this way I cannot choose any of the ids to be unique. The result is
> nothing is updated.
>
> I wonder if I am the only one facing this problems with CForms. I think
> other people will need this enhancement. After thinking in how to solve
> this I come to 2 posible solutions:
>
> 1- The Best: Allow repeater to define unique-row with more than 1 field.
>
> 2- Based in an special requirement: I have a fixed length of rows in the
> repeater to display and the user cannot change the number of rows. The
> user just fill data. I can call it a FixedLengthRepeater. Of course I can
> do this based on the current Simple or Temp Repeater. But I don't like the
> idea of this special purpose repeater.
>
> Back to (1), in order to allow multiple unique-ids, we need to change from
> attributes to elements: @unique-row-id and @unique-path
>
> So in this way we can write:
>
> 
>   
> 
> 
>   
>   
> 
> 
> 
> 
>   
> 
>
> WDYT?
>
> I need to have something like this for tomorrow. If this is OK. I will
> start to work right now on this.
>
> Best Regards,
>
> Antonio Gallardo
>

Re: [CForm]two question/suggestion about multi-value field

[Bruno Dumon]

On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote:

> 
> >2.Sometime we need to just display multi-value as text like
> ,but I only found binding can only bind multivalue-field
> with multi-value(only in cvs now).Can/Should cocoon form provide
> multi-value binding to output widget?
> >
> 
> I think no. Why do you want to bind it to wd:output?

I would think for the same reason one would otherwise wd:output instead
of wd:field. In this case one would however need a wd:multivalueOutput
widget.

>  If you want to
> *render* it as text output, you should use wi:styling type=output.
> 
> Vadim

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: FlowScript in 2.1.5-dev has gone tango uniform

[Jeremy Quinn]

On 2 Mar 2004, at 18:42, Jeremy Quinn wrote:

To restate the basic problem :

I have 2 URLs each served by a different sub-sitemap, each loading a 
different (single) flowscript. Each flowscript has some common 
function names, eg. index(). For debugging purposes, each function 
outputs it's name etc. to the flow log.

load URL 1 : the correct script and function run fine
load URL 2 : the same-named function in the flowscript file for URL 1 
runs.

Some further info:

Rolling back to Cocoon 2.1.4 Release, has fixed the problem.

regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature

Re: Java chokes on logkit-1.2.2

[JD Daniels]

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:

Did you try a clean build?
 

It's not a cocoon cvs; it's copy of cocoon libs into web-inf/lib.


I have the same jdk and for me it works perfectly :)
The second exception you get is due to a change in excalibur-logger.
The logkit.xconf needs an entry for the root category (category
without a name). I have fixed this some days ago in the CVS.
 

Ah! Did not expect migration issues from 2.1.4 to 2.1.5-dev. Ok, thanks.

Vadim



Did you figure how to fix this? I just did a fresh cvs checkout and 
clean build and get the same error (jdk 1.4.1_01)

JD

Re: [CForm]two question/suggestion about multi-value field

[Vadim Gritsenko]

Bruno Dumon wrote:

On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote:

 

2.Sometime we need to just display multi-value as text like
 

,but I only found binding can only bind multivalue-field
with multi-value(only in cvs now).Can/Should cocoon form provide
multi-value binding to output widget?
   

I think no. Why do you want to bind it to wd:output?
   

I would think for the same reason one would otherwise wd:output instead
of wd:field. In this case one would however need a wd:multivalueOutput
widget.
 

Yes, but why not type=output?

Vadim

Re: Java chokes on logkit-1.2.2

[Vadim Gritsenko]

JD Daniels wrote:

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:

Did you try a clean build? 


It's not a cocoon cvs; it's copy of cocoon libs into web-inf/lib.

...

Did you figure how to fix this? I just did a fresh cvs checkout and 
clean build and get the same error (jdk 1.4.1_01)


I killed manifest from logkit, which is the reason.

Vadim

Re: Java chokes on logkit-1.2.2

[JD Daniels]

Vadim Gritsenko wrote:

JD Daniels wrote:

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:

Did you try a clean build? 


It's not a cocoon cvs; it's copy of cocoon libs into web-inf/lib.


...

Did you figure how to fix this? I just did a fresh cvs checkout and 
clean build and get the same error (jdk 1.4.1_01)


I killed manifest from logkit, which is the reason.

Vadim



ok


   manifest?
   I have never actually messed with any of the
   logkit stuff.. the defaults do just what I want :S

Re: Java chokes on logkit-1.2.2

[JD Daniels]

JD Daniels wrote:

Vadim Gritsenko wrote:

JD Daniels wrote:

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:

Did you try a clean build? 




It's not a cocoon cvs; it's copy of cocoon libs into web-inf/lib.



...

Did you figure how to fix this? I just did a fresh cvs checkout and 
clean build and get the same error (jdk 1.4.1_01)




I killed manifest from logkit, which is the reason.

Vadim



ok


   manifest?
   I have never actually messed with any of the
   logkit stuff.. the defaults do just what I want :S



oops.. ok i get it now :)

Re: whitespace cleanup and efficiency drive

[Joerg Heinicke]

On 02.03.2004 14:34, Vadim Gritsenko wrote:

We have quite a number of these problem files in cocoon-2.1
I noticed a new one come in today with Carsten's commit
of portal.samplesxconf
  


The recent commit of all the *.license files proved that Eclipse
is the culprit. Until their Bug 15119 is fixed (please vote for it),
the Eclipse users should use the workaround to add the unknown
text types.
The find_binary_text.pl script reports these problems:
.ai
.css
.dtd
.gt
.in
 

...

You know that you can use cvs admin to change keyword substitution, right?
Of course, but you *have* to do it as Eclipse uses binary as default and 
not text like the command line cvs client. We never took care about it 
as it probably never was a problem. But since almost everybody seems to 
use Eclipse also for committing and especially adding files we had some 
issues in our CVS.

Joerg

Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Geoff Howard]

Joerg Heinicke wrote:

On 02.03.2004 22:08, Geoff Howard wrote:

Hi,

Most of the time when I run XConfToolTask, it works
fine, but sometimes I get the following error:
IOException: java.net.ConnectException: Connection
timed out: connect
Any idea what's the problem here?




Which version of Cocoon?  The xpatch task is supposed to disable 
resolving of remote dtds but the underlying xalan/xerces feature 
was broken.  To be honest, I don't remember where it left off, when 
it broke or if/when it was fixed.




It was Xerces 2.6.0, but fixed for Cocoon 2.1.4.


Thanks, Joerg.  I had it in my head that it was "fixed" but the 
problem didn't go away.  Am I loonier than I thought?


The problem after an upgrade is the remaining of the xerces JAR at 
tools/lib. The JARs are only copied on demand to that place, i.e. if 
no xerces JAR exists at that place at all. If there is already a 2.6.0 
JAR it won't be replaced if you have updated only lib/endorsed. This 
is at least true for build.bat. build.sh copies the endorsed libs 
always to tools/lib, but does not remove old versions.

Is that explanation helpful?

Why are these three files copied at all? When the java.endorsed.dirs 
property is set (which is to lib/endorsed) the JARs are on the 
classpath. If we need to copy them the build script should probably 
made a bit more intelligent on this issue.


No fair, I figured that out on my own but now you won't believe me... :)

I have no idea why the build copies those files, and I think no one 
does.  Anyone?  In fact, the batch file spits out bogus file not found 
warnings at the beginning of every build which has confused newbies.

Anyone against stopping the copy from lib/endorsed to toos/lib, and 
pointing the ant/jetty endorsed dir to lib/endorsed directly?  If not, 
then we need to fix the build scripts so that we are not shielded from 
endorsed lib updates in the build.

Geoff

Re: FlowScript in 2.1.5-dev has gone tango uniform

[Sylvain Wallez]

Jeremy Quinn wrote:

On 2 Mar 2004, at 18:42, Jeremy Quinn wrote:

To restate the basic problem :

I have 2 URLs each served by a different sub-sitemap, each loading a 
different (single) flowscript. Each flowscript has some common 
function names, eg. index(). For debugging purposes, each function 
outputs it's name etc. to the flow log.

load URL 1 : the correct script and function run fine
load URL 2 : the same-named function in the flowscript file for URL 1 
runs.

Some further info:

Rolling back to Cocoon 2.1.4 Release, has fixed the problem.


I made changes to flowscript after 2.1.4 to remove the dependency of 
flowscript on Environment (it now uses only the Redirector). This led to 
changing the key used to store global scopes in the session (see 
FOM_JavaScriptInterpreter.getSessionScope()), but I don't know how it 
can produce what you encounter.

I'll give a look at this tomorrow.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Joerg Heinicke]

On 02.03.2004 22:51, Geoff Howard wrote:

The problem after an upgrade is the remaining of the xerces JAR at 
tools/lib. The JARs are only copied on demand to that place, i.e. if 
no xerces JAR exists at that place at all. If there is already a 2.6.0 
JAR it won't be replaced if you have updated only lib/endorsed. This 
is at least true for build.bat. build.sh copies the endorsed libs 
always to tools/lib, but does not remove old versions.

Is that explanation helpful?

Why are these three files copied at all? When the java.endorsed.dirs 
property is set (which is to lib/endorsed) the JARs are on the 
classpath. If we need to copy them the build script should probably 
made a bit more intelligent on this issue.


No fair, I figured that out on my own but now you won't believe me... :)

I have no idea why the build copies those files, and I think no one 
does.  Anyone?  In fact, the batch file spits out bogus file not found 
warnings at the beginning of every build which has confused newbies.
Yes, the windows build tests for many locations where to find the JARs.

Anyone against stopping the copy from lib/endorsed to toos/lib, and 
pointing the ant/jetty endorsed dir to lib/endorsed directly?
The java.endorsed.dirs already point to lib/endorsed.

 If not, 
then we need to fix the build scripts so that we are not shielded from 
endorsed lib updates in the build.
It's just an issue of the build. I tried it without the libs at 
tools/lib and it does not work:

BUILD FAILED
java.lang.IllegalArgumentException: No attributes are implemented
at 
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.setAttribute(Docum
entBuilderFactoryImpl.java:93)
at XConfToolTask.execute(Unknown Source)

Hmm, don't know why it falls back to Crimson (from JDK I guess) though 
endorsed dirs are set and Ant works without the JARs in tools/lib.

Joerg

Re: FlowScript in 2.1.5-dev has gone tango uniform

[Antonio Gallardo]

Hi Jeremy:

Are you updated your endorsed libs? Please don't get offended by the
obvious question, but I thought this problem is related to this issue. Can
you check this?

Best Regards,

Antonio Gallardo.

Jeremy Quinn dijo:
> Hi All
>
> I just upgraded my copy of Cocoon to today's CVS version.
>
> A (previously working) site that uses a lot of FlowScript has gone
> completely TU.
>
> I am getting a lot of this :
>
> org.apache.cocoon.ResourceNotFoundException: Function
> "javascript:album()" not found
>
> Where it worked before the update.
>
> But stranger still, while I was doing some testing, I got an error that
> said that a script that was not even referred to by the current
> pipeline, did not contain the function I was calling !!
>
> Do what ?!?
>
> Have there been some changes to the FlowScript infrastructure that
> could result in the wrong FlowScript file being used under certain
> circumstances?
>
> I have several flowscripts, used independently by different
> Sub-SiteMaps, that have the same function names. The first SiteMap I
> invoke, works (does not matter which one) all subsequent invocations of
> pipelines with similar (but different) FlowScripts fail.
>
>
> Any ideas anyone?
>
>
> regards Jeremy

Re: Applying SourceWritingTransformer to file used in pipeline

[Joerg Heinicke]

On 27.02.2004 11:31, Remmerie Bart wrote:

It appears to be impossible to use the SourceWriting transformer to a file
that is in use by the pipeline.
Of course it is so, you must have in mind that the file content is 
streamed! And what should be the use case for writing a file *while* you 
are reading it?

Does anyone have a workaroud / alternative for this ?
I guess FlowScript with calls to different pipelines.

Joerg

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

[Joerg Heinicke]

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 and url(#), even 
though the reference is resolved within the same  element (and 
resolves correctly when using FOP standalone...must be relying on 
different behavior than the Cocoon URI resolving provides?).
That's strange as no Cocoon URI resolving does not take part here. 
Sylvain tried to replace the resolver with the Cocoon one for usage of 
Cocoon pseudo protocols, but this broke the local URIs (#), so it was 
reverted. It lived from Feb, 4th, to Feb 8th - I hope your Cocoon is not 
from that time. Cocoon 2.1.4 does not contains this.

If I just try to use the FOP version of Batik (Cocoon fop-0.20.5.jar) I 
What does it mean? No Batik at all? Cocoon's fop JAR as standalone?

get a No Such Method in Batik.
java.lang.NoSuchMethodError: 
org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/parser/UnitProcessor$Context; 

So it looks like Cocoon's version of FOP is using a different (newer?) 
version of Batik. But that raises the question, was the Cocoon version 
of FOP taken from CVS and is really post 0.20.5 release?
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. So we rebuilt Fop with this new Batik and the 
problems seemed to be gone. The FOP 0.20.5 release uses Batik 1.5 beta 4.

I also tried with the maintenance branch CVS head of FOP with no 
difference.
Hmm, head *or* branch :) I guess you mean the recent stuff from the branch.

I think I'll look into writing a Serializer that invokes the standalone 
FOP as though it was an external program so I can pickup the versions of 
FOP/Batik I need to make this work.
Not a very integrative solution ...

From: "J.Pietschmann"

Can anyone tell me how the Cocoon fop and batik jar files are 
generated and how that is different from the jars supplied with FOP?


THere were some Cocoon releases which shipped with a different
Batik jar than the corresponding FOP release, partly due to
interface changes in Batik which forced FOP to use a CVS
snapshot. I don't know of the current state, but the latest
Batik was released after the latest FOP release, if Cocoon
grabbed the latest Batik jar, there are certainly some differences.
After Batik 1.5 b 2 we had b5 and the 1.5 release in use. The latter two 
are newer then FOP 0.20.5 and its Batik 1.5 b4. I would like to see this 
solved for Cocoon finally.

For Steve it should work to use Fop 0.20.5's jar and its batik.jar (the 
1.5 b4) and to replace the Cocoon's versions of these two jars.

Joerg

Re: Update to batik 1.5.1

[Joerg Heinicke]

On 28.02.2004 04:00, Carlos Araya wrote:

Before you go updating the libraries, realize that FOP on Cocoon's CVS
depends on a specific version of Batik... PLEASE, please don't update
without knowing what the dependencies are.
Carlos, do you use the current combination of Fop 0.20.5 and Batik 1.5? 
Do they work for you?

Joerg

Re: workflow block commited

[Gregor J. Rothfuss]

Carsten Ziegeler wrote:

I see the following minimum todo list from the Cocoon POV:
- Use the Avalon Logging instead of log4j directly
- Use Avalon components
- Move to the source resolver instead of directly reading files
- Don't use the Xerces XPath API directly, use Avalon XPath component
- The same with the parser
I don't see any Cocoon specific component in the workflow block.
Can you add some Cocoon specific ones and some minimum docs on
how to use it?
thanks for the list!

i'll add it to a TODO file inside the block.

-gregor

--
Gregor J. Rothfuss
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://wyona.com   http://cocoon.apache.org/lenya
[EMAIL PROTECTED]   [EMAIL PROTECTED]

[HELP!] - RE: Java chokes on logkit-1.2.2

[Antonio Gallardo]

Hi:

I already read 3 or 5 times all the mails:

http://marc.theaimsgroup.com/?t=107823977800010&r=1&w=2

But I don't understand how to solve the problem. :-(

Can someone describe a little bit more what is needed to solve the problem?

Please help! ;-)

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 27385] New: - New store implementation supporting JCS as a persistent store

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27385

New store implementation supporting JCS as a persistent store

   Summary: New store implementation supporting JCS as a persistent
store
   Product: Cocoon 2
   Version: 2.1.4
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


An implementation of the cocoon persistent store which uses the JCS libraries 
for storage.

Full instructons and description available within archive readme.

DO NOT REPLY [Bug 27385] - New store implementation supporting JCS as a persistent store

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27385

New store implementation supporting JCS as a persistent store





--- Additional Comments From [EMAIL PROTECTED]  2004-03-03 00:58 ---
Created an attachment (id=10643)
Implementation of JCS store

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

[Pier Fumagalli]

On 1 Mar 2004, at 08:33, Ugo Cei wrote:

Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in 
Cocoon 2.2?
Here is my +1
-0.5

Even though 1.4 is available for most platforms, and I've been using 
it exclusively for quite a long time, I still think there are many 
environments where people are forced to use 1.3 (not to mention 1.2) 
and upgrading wouldn't be an easy task.

If, and when, we have something that absolutely requires 1.4 (say, a 
new caching system based on NIO, like Pier suggested), we might 
reconsider this requirement. Doing it now would just alienate many 
users without really buying us anything important.

I suggest to repeat this vote when we have a proposed time frame for 
the release of 2.2.
I wanted for someone to pull out a vote on this one (not me) because 
I'm going to vote (as Ugo) -0.5 for the REQUIREMENT of Cocoon 2.2 to 
operate only on J2SDK >= 1.4.

Ok, don't get me wrong, I am the one who initially said it would be so 
cool, but I believe that for 2.2 we have much bigger fishes to fry.

NIO is nice (indeed) for a bunch of things, and as Alan pointed out, 
using RegEx in the 2.2 sitemap would be a killer, but IMVHO for this 
release we have MUCH BIGGER fishes to fry: blocks and continuations.

Continuations, well, easy... We're still running on a forked JavaScript 
interpreter, and personally I don't care much about any other language 
:-D

And I started picking back on Avalon and family in the past few weeks 
to deploy some stuff, and yeah, it's a nice package, but I still don't 
understand the full complexity of why certain approaches (to my mind 
counterproductive) were chosen...

IMVHO, 2.2 should be focused on the platform, blocks, compoents, 
continuations to a SOLID and STABLE implementation (did Stefano say few 
months ago that he felt like we were building sand?). I do feel that 
the Cocoon might somehow in some very limited case going off without 
solidifying its foundations, and this (2.2) is one good opportunity to 
put some solid concrete down there, EVERYWHERE...

A cache based on NIO? Fine, if it's a block, I can swap it in at any 
time. RegEx for the sitemap? If matchers are pluggable, it's fairly 
easy.

So, IMVHO, yes, 2.2 could be a requirement for some blocks, but someone 
(and not me :-) has to shake the foundations, and put some concrete 
where we need it...

We'll have components based on 1.4, sure, but if we build our 
architecture pluggable enough, well, I don't see how that would impact 
people running 1.3.

On 1 Mar 2004, at 18:37, Stefano Mazzocchi wrote:
We don't have to decide right now, but I think it would be good to 
give the signal "please go ahead and experiment if you think it makes 
sense, we'll judge depending on the advantages".
I'd say, let's keep 1.4 in mind in solidifying the foundations, and 
let's grasp those advantages we can get now out of it by deploying a 
modular architecture... The strict requirement can come later on, when 
we'll have to decouple cocoon from it's Connection/Thread paradigm and 
move the network stack away from the blocking model.

	Pier

Re: Gump

[Stefano Mazzocchi]

Hunsberger, Peter wrote:

Not sure, I think you're on your own on this one...
don't worry, I'm so used to that it doesn't even hurt anymore

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] - Entry level JSDK 1.4 in Cocoon 2.2

[Stefano Mazzocchi]

Pier Fumagalli wrote:

using RegEx in the 2.2 sitemap would be a killer
I thought we already had regexp in the sitemap.

--
Stefano, puzzled


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [CForm]two question/suggestion about multi-value field

[Bruno Dumon]

On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote:
> Bruno Dumon wrote:
> 
> >On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote:
> >
> >  
> >
> >>>2.Sometime we need to just display multi-value as text like
> >>>  
> >>>
> >>,but I only found binding can only bind multivalue-field
> >>with multi-value(only in cvs now).Can/Should cocoon form provide
> >>multi-value binding to output widget?
> >>
> >>
> >>I think no. Why do you want to bind it to wd:output?
> >>
> >>
> >
> >I would think for the same reason one would otherwise wd:output instead
> >of wd:field. In this case one would however need a wd:multivalueOutput
> >widget.
> >  
> >
> 
> Yes, but why not type=output?

because an output widget doesn't read its value from the request. With a
normal (multivalue)field widget, the value can always be modified by
adding the appropriate request parameters.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

A different luceneIndexTtransformer

[Nicolas Maisonneuve]

hy,
i updated a old modified luceneIndexTransformer 
that i made last year.
This LuceneIndexTransformer is more general (more 
low level) and can be used to index all kind of resources (not only HTML page). 

 
a typic pipeline to index would be :
ressource -> XSLT -> 
LuceneIndexTransformer-> xml results
 
a sample : 
 
http://apache.org/cocoon/lucene/1.0" 

create="true" 
analyzer="org.apache.lucene.analysis.standard.StandardAnalyzer"
directory="d:/indexbase"
merge-factor="100">
    
        
sqdqsdq
        
 bla bal blalael balbal 

        
10/12/2002 

        (see java 
API Class SimpleDateFormat for more explanation about the dateFormat 
attribut)    

        
just indexed information (not 
stored)
        
just stored information (not 
indexed)
    

    

        
Mr Author 
 (boost the field for the search (see Lucene 
documentation))
        
french
    

< /lucene:index> 
 
To delete documents

     (delete all documents with the field 
author ="Mr Author")
    
< /lucene:delete> 
 
Example of Output Source 
< lucene:index nbdocuments="2"/>
< lucene:delete 
nbdocuments="1"/>
 
Maybe someone would be 
interessed...
 
NIcolas Maisonneuve
 
package org.apache.cocoon.transformation;

import java.io.File;
import java.io.IOException;
import java.io.Serializable;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Map;

import org.apache.avalon.excalibur.pool.Recyclable;
import org.apache.avalon.framework.activity.Disposable;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.context.Context;
import org.apache.avalon.framework.context.ContextException;
import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.Constants;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.CacheableProcessingComponent;
import org.apache.cocoon.components.search.LuceneCocoonHelper;
import org.apache.cocoon.environment.SourceResolver;
import org.apache.cocoon.transformation.AbstractTransformer;
import org.apache.excalibur.source.SourceValidity;
import org.apache.excalibur.source.impl.validity.NOPValidity;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.document.DateField;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.IndexReader;
import org.apache.lucene.index.IndexWriter;
import org.apache.lucene.index.Term;
import org.apache.lucene.store.*;

import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.AttributesImpl;

/**
 * A lucene index creation transformer.
 * @author Nicolas Maisonneuve
 *
 Example of input source:
 
  to Index
 
 
 
 sqdqsdq
  bla bal blalael balbal 
 10/12/2002
 (see java API Class SimpleDateFormat for more explanation about the dateFormat attribut)
 just indexed information (not stored)
 just stored information (not indexed)
 
  
 Mr Author   (boost the field for the search (see Lucene documentation))
 french
 
 < /lucene:index>
 To delete 
 
   (delete
 all documents with the field author ="Mr Author") 
 < /lucene:delete>
 Example of Output Source
 ;
 <
  lucene:index nbdocuments="2"/>
 <
 lucene:delete nbdocuments="1"/>
 
 */

public class LuceneIndexTransformer
extends AbstractTransformer
implements Disposable, Recyclable,
Configurable {

  public static final String ANALYZER_CLASSNAME_CONFIG = "analyzer-classname";
  public static final String ANALYZER_CLASSNAME_PARAMETER =
  "analyzer-classname";

  public static final String DIRECTORY_CONFIG = "directory";
  public static final String DIRECTORY_PARAMETER = "directory";

  public static final String MERGE_FACTOR_CONFIG = "merge-factor";
  public static final String 

Re: [XConfToolTask] java.net.ConnectException: Connection timed out: connect

[Joerg Heinicke]

On 02.03.2004 22:08, Geoff Howard wrote:

Hi,

Most of the time when I run XConfToolTask, it works
fine, but sometimes I get the following error:
IOException: java.net.ConnectException: Connection
timed out: connect
Any idea what's the problem here?


Which version of Cocoon?  The xpatch task is supposed to disable 
resolving of remote dtds but the underlying xalan/xerces feature was 
broken.  To be honest, I don't remember where it left off, when it 
broke or if/when it was fixed.


It was Xerces 2.6.0, but fixed for Cocoon 2.1.4.
Thanks, Joerg.  I had it in my head that it was "fixed" but the problem 
didn't go away.  Am I loonier than I thought?
The problem after an upgrade is the remaining of the xerces JAR at 
tools/lib. The JARs are only copied on demand to that place, i.e. if no 
xerces JAR exists at that place at all. If there is already a 2.6.0 JAR 
it won't be replaced if you have updated only lib/endorsed. This is at 
least true for build.bat. build.sh copies the endorsed libs always to 
tools/lib, but does not remove old versions.

Is that explanation helpful?

Why are these three files copied at all? When the java.endorsed.dirs 
property is set (which is to lib/endorsed) the JARs are on the 
classpath. If we need to copy them the build script should probably made 
a bit more intelligent on this issue.

Joerg

Re: Gump

[Stefano Mazzocchi]

Hunsberger, Peter wrote:

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:



I have a RT ready for gump that would allow to solve these 
issues... but 
I need to work more on this since it appears to be a pretty tough 
computational problem of graph analysis.


We do have generalized hedge generator code (both in a Cocoon sense and
in a flat query to data structure sense) that I might be able to get you
a copy of ;-)...  However, I suspect you need the opposite of what we
have; something to break down tree structured data into hedges and look
for intersections (cycles)?
oh, nono, the problem is completely different: when a project doesn't 
compile, who's fault is that?

Currently gump has information such as

 (A) --(depends on)--> (B)

the problem with this is that if A breaks, it could be because of B's 
fault or because of A's fault, you can't tell.

What I'm going to propose is to have bidimensional dependencies:

 (A,20040302) --(depends on)--> (B,20040212)

At this point, gump can do multiple builds based on the timestamp and it 
is possible figure out who broke what and when, in theory point at the 
very single commit to blame.

The problem is that the complexity of such trellis grows very big very 
quickly. I still have to understand if it's duable at all!

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature