Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Tim Larson]

On Sat, Mar 06, 2004 at 07:05:01AM +, Tim Larson wrote:
> On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote:
> > On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:
> > >Tim Larson wrote:
> > >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
> > >>> Package: org.apache.cocoon.cforms
> > >>>
> > >>>here I would go "forms" instead. package naming is where the estate 
> > >>>really is, where class collissions might happen.
> > >>
> > >>I understand how this seems like a good place for the battleground,
> > >>but to introduce a new winner it looks like this would force us to
> > >>break code compiled against the previous major version because we
> > >>would be stealing the class and interface names for the new version.
> > >>Does the new block system somehow solve this problem like via
> > >>classloaders or something else?
> > >
> > >eh, very good question, actually. I spent a few hours discussing with 
> > >Pier about this yesterday over IM. Pier, as usual, sees the very core 
> > >problem and I always miss ;-)
> 
> 
> 
> Ok, so to sum up the version/classloading discussion, this plan
> (using 'forms' for the package naming) involves burning the users
> on major version upgrade by for most practical purposes breaking
> the previous major forms version when introducing the new version.
> 
> I agree with the idea of forcing core developers to choose between
> adding enhancements incrementally versus making a *major* effort to
> prove that their new revolutionary version deserves to unseat the
> current framework, but making things tough for the users is going
> too far.  I must be missing something, would somebody enlighten me?

I talked with Antonio on IRC and he had a good idea (IMHO) for this.
Make the package name start as either o.a.c.forms or o.a.c.forms1
and a new major version can go to o.a.c.forms2.  This preserves the
ONE-and-only current forms framework concept (identified by the
current stable version number), while not introducing any classloading
version problems.  Also, the actual class names and interface names
are not polluted with version numbers.

WDYT?
--Tim Larson

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Tim Larson]

On Fri, Mar 05, 2004 at 11:41:15PM +, Pier Fumagalli wrote:
> On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:
> >Tim Larson wrote:
> >>On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
> >>> Package: org.apache.cocoon.cforms
> >>>
> >>>here I would go "forms" instead. package naming is where the estate 
> >>>really is, where class collissions might happen.
> >>
> >>I understand how this seems like a good place for the battleground,
> >>but to introduce a new winner it looks like this would force us to
> >>break code compiled against the previous major version because we
> >>would be stealing the class and interface names for the new version.
> >>Does the new block system somehow solve this problem like via
> >>classloaders or something else?
> >
> >eh, very good question, actually. I spent a few hours discussing with 
> >Pier about this yesterday over IM. Pier, as usual, sees the very core 
> >problem and I always miss ;-)



Ok, so to sum up the version/classloading discussion, this plan
(using 'forms' for the package naming) involves burning the users
on major version upgrade by for most practical purposes breaking
the previous major forms version when introducing the new version.

I agree with the idea of forcing core developers to choose between
adding enhancements incrementally versus making a *major* effort to
prove that their new revolutionary version deserves to unseat the
current framework, but making things tough for the users is going
too far.  I must be missing something, would somebody enlighten me?

--Tim Larson

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

[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=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 06:57 ---
I will start to depurate the 279 file list without Licenses...

Re: From Woody to CocoonForms

[Antonio Gallardo]

Reinhard Pötz dijo:
> All other form implementation will be deprecated soon. IMO we should
> make this clear by moving those blocks into a "deprecated-blocks"
> directory.
>
> WDOT?

We often talk about this, but nobody dares to change all them to
deprecated blocks. Anyway, here is my:

+1

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

[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=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 06:25 ---
After the 2nd run, there where skipped 279 files of unknown type. List of
unknown filename extensions (Add new types to this script):
=14 .cgi=1 .cvsignore=3 .dcl=1 .dtd=27 .ent=4 .grm=4 .htm=6 .html=41 .jsp=2
.mf=1 .mod=3 .pen=6 .pl=2 .project=1 .rdf=64 .rdfs=7 .rep=1 .rng=5 .template=2
.txt=60 .types=1 .vm=16 .wsdd=4 .wsdl=2 .xcat=1

I choosed to not add this types because some of them cannot have our copyright,
there are W3c copyright or others, please give some advise.

AFAIK, the count 279 is lower: 
the 64 *.rdf files that are not in our copyright,
the 7  *.rdfs files that are not in our copyright,
and others

Here is the output of the lastest run.

$ perl insert_license.pl /cocoon-2.1/src/ 1999-2004 > logfile1.txt

Total 4231 text files were investigated.
New licenses were inserted in 178 files.
Skipped 3760 files with an existing license:
(v2.0=3717, v1.1=12, v1.0=0)
Skipped 20 XML files with missing XML Declaration.
Skipped 279 files of unknown type.
List of unknown filename extensions (Add new types to this script):
=14 .cgi=1 .cvsignore=3 .dcl=1 .dtd=27 .ent=4 .grm=4 .htm=6 .html=41 .jsp=2
.mf=1 .mod=3 .pen=6 .pl=2 .project=1 .rdf=64 .rdfs=7 .rep=1 .rng=5 .template=2
.txt=60 .types=1 .vm=16 .wsdd=4 .wsdl=2 .xcat=1
List of all unique filename extensions:
=14 .ccf=1 .cgi=1 .css=27 .cvsignore=3 .dcl=1 .dtd=27 .egrm=1 .ent=4 .grm=4
.gt=7 .htm=6 .html=41 .java=2021 .javascript=1 .jdo=1 .jj=2 .js=132 .jsp=2
.jx=18 .jxt=2 .meta=21 .mf=1 .mod=3 .pagesheet=2 .pen=6 .pl=2 .project=1
.properties=7 .rdf=64 .rdfs=7 .rep=1 .rng=5 .roles=1 .samplesxconf=2
.samplesxpipe=1 .script=2 .sql=3 .stx=3 .svg=5 .template=2 .txt=60 .types=1
.vm=16 .wsdd=4 .wsdl=2 .xcat=1 .xconf=72 .xegrm=1 .xgrm=5 .xhtml=13 .xlex=7
.xlog=12 .xmap=170 .xmi=2 .xml=895 .xroles=27 .xsamples=41 .xsd=3 .xsl=289
.xslt=21 .xsp=104 .xtest=19 .xweb=8 .xwelcome=3

Uri-prefix in sitemap components

[Oscar Picasso]

Hi,

In a project I am working on, I need to get the current uri prefix from inside
a sitemap component (an action in that case).

I doesn't seem possible to get it directly.

1- Do I miss something?

2- If not, I would be glad to add this feature. Is anyone interested?

Oscar

__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

DO NOT REPLY [Bug 25483] - [PATCH] SendMailTransformer accumulating attachments and addresses

[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=25483

[PATCH] SendMailTransformer accumulating attachments and addresses

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 05:11 ---
Patch applied. The next time please provide a unified diff, because the line
numbers can change because of other changes. Exactly this was the reason as
yesterday the new Apache license 2.0 was applied with much less lines. Thanks
anyway.

Joerg

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

[Stefano Mazzocchi]

Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:

I would do

  http://apache.org/cocoon/cforms/1.0#definition


Stefano, how could you???!!!

   http://apache.org/cocoon/forms/1.0#definition
yeah right, gosh, you got me there ;-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 25403] - [PATCH] EncodeURLTransformer unconditionally creates session

[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=25403

[PATCH] EncodeURLTransformer unconditionally creates session

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 04:59 ---
The code itself points to bug #13855, hope your patch works though. At least it
makes sense for me.

DO NOT REPLY [Bug 25304] - AggregateField enhancement

[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=25304

AggregateField enhancement





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 04:42 ---
Vadim, does your latest aggregate field patch match bug? I think so.

DO NOT REPLY [Bug 25098] - SQLTransformer fails to return number of rows updated

[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=25098

SQLTransformer fails to return number of rows updated





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 04:30 ---
Created an attachment (id=10678)
the patch

DO NOT REPLY [Bug 25098] - SQLTransformer fails to return number of rows updated

[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=25098

SQLTransformer fails to return number of rows updated

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[PATCH] SQLTransformer fails|SQLTransformer fails to
   |to return number of rows|return number of rows
   |updated |updated



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 04:30 ---
Please provide a patch with only the changes:
"cvs diff -u
src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer".
This would allow us to apply it even if some other things in the file have
changed in the meantime (sometimes with some work to do by hand).

But a complete file prevents us from doing it with an acceptable effort: If I
replace my latest version of SQLTransformer with your version and make the diff
I see all changes between the version you patched and now - at the end I see
nothing. For that reason also the above "cvs diff" would not help anymore. If
you have Linux you can do a
"diff -u SQLTransformer.java.orig SQLTransformer.java.new".

The last alternative (that's how I did it now) is to check out the
SQLTransformer by version/date/tagged and do the cvs diff against this version.
Unfortunately you also touched all empty lines, so that I had to do a diff
ignoring whitespaces. After reapplying this on recent version of SQLTransformer
I also had to indent the code correctly. I hope nothing got lost.

Joerg

Re: Committing files with new licenses with perl script.

[Antonio Gallardo]

Hi:

I am back to work.

Best Regards,

Antonio Gallardo

Antonio Gallardo dijo:
> Hi:
>
> My ISP is working back. I am committing files with new licenses.
>
> This is just a 1st step. I need to make some changes before continue. Now,
> I am going to dinner with my wife. After an hour I will continue on the
> work. I will post a reply to this mail when I am back and then then I
> finish the work. Please don't rant until I finish the work. :-D
>
> Best Regards,
>
> Antonio Gallardo
>

DO NOT REPLY [Bug 25094] - Move Woody into CocoonForms block

[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=25094

Move Woody into CocoonForms block





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 03:49 ---
Recent threads:
http://marc.theaimsgroup.com/?t=10784892051&r=1&w=4
http://marc.theaimsgroup.com/?t=10785005733&r=1&w=4
http://marc.theaimsgroup.com/?t=10785067065&r=1&w=4

DO NOT REPLY [Bug 25054] - fo:basic-link

[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=25054

fo:basic-link

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 03:45 ---
Please ask on the mailing lists for further help or reopen the bug if you can
provde more information.

DO NOT REPLY [Bug 25021] - [PATCH] ZipArchiveSerializer does not check for non existing files

[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=25021

[PATCH] ZipArchiveSerializer does not check for non existing files

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 03:44 ---
For me a ZIP file is not created at all when one source does not exist, so IMO
it works like expected. I tested it with Cocoon 2.0 head from CVS. Either it was
fixed between 2.0.4 and now or you must have something special in your
environment/configuration. Are you ok with closing the bug?

Joerg


Cocoon 2 - Resource not found

type resource-not-found

message Resource not found

description The requested URI "/cocoon-2.0/samples/hello-world/hello.zip" was
not found

sender org.apache.cocoon.servlet.CocoonServlet

source Cocoon servlet

cause

D:\cocoon-2.0\build\cocoon\webapp\samples\hello-world\test (Das System kann die
angegebene Datei nicht finden)

request-uri

/cocoon-2.0/samples/hello-world/hello.zip

path-info

samples/hello-world/hello.zip

DO NOT REPLY [Bug 25110] - [Roadmap] CocoonForms - release 1.0

[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=25110

[Roadmap] CocoonForms - release 1.0

This bug depends on bug 24893, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

Committing files with new licenses with perl script.

[Antonio Gallardo]

Hi:

My ISP is working back. I am committing files with new licenses.

This is just a 1st step. I need to make some changes before continue. Now,
I am going to dinner with my wife. After an hour I will continue on the
work. I will post a reply to this mail when I am back and then then I
finish the work. Please don't rant until I finish the work. :-D

Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 22400] - [PATCH] SQLTransformer to optionally preserve case of column names

[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=22400

[PATCH] SQLTransformer to optionally preserve case of column names

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 02:10 ---
Applied in the following way:


  preserve | uppercase | lowercase
  
...
  
  ...


If not specified, it behaves like before the patch: lowercase. If specified with
invalid value the case is preserved. Maybe this should be documented somewhere.

Thanks for your patch, please cross-check and close the bug afterwards.

Joerg

RE: JCSStore causes stack overflow?

[Corin Moss]

Hi,

I'd first like to make sure that we're all straight on the issues that
Geoff just raised first - the issue of absolute persistence especially
:)

As for the email, sorry about that Antonio - I was using my company's
Outlook webmail, and I think it does odd things such as that.

I also apologise for the huge disclosure sig at the bottom of all my
mails - I can't help it - it gets put on at the gateway.

Right, I've done apologising now ;)

-Original Message-
From: Antonio Gallardo [mailto:[EMAIL PROTECTED]
Sent: Saturday, 6 March 2004 2:49 p.m.
To: [EMAIL PROTECTED]
Subject: RE: JCSStore causes stack overflow?


Hi Corin:

That means JCS is a win-win game to us! Lets define JCS as the default
cache system in the new Cocoon release!

BTW, your mail comes in a weird for to me. As an attachment of another
empty mail with a disclosure notice.

Best Regards,

Antonio Gallardo.


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: Turning off default MRU store

[Corin Moss]

Hiya,

That's a very pertinent set of questions - I'll answer as best I can
below, the only caveat is that I won't proclaim myself a JCS expert,
given that I was really only introduced to it a few days ago ;)

-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Saturday, 6 March 2004 2:38 p.m.
To: [EMAIL PROTECTED]
Subject: Re: Turning off default MRU store


Corin Moss wrote:

>Hi Guys,
>
>I think the thing to remember here is that it's the Disk Cache
>implementation that has this behaviour, and that it's very easy to use
>a different store type if the user feels it's necessary.  There are
>other, "safer" store implementations we can use - the only problem in
>this case is that the index is kept in memory (which is what makes it
>so fast.) If the user decides that this is inappropriate for them, the
>change to a different store type is very easy to make within the
>config.
>
>I think that moving to a filesystem store would be counter-productive,
>as the thing that JCS provides is total flexibility of store type.
>
>Just my thoughts :)
> 
>

Ok, I apologize that I just can't look into this myself right now, but
let me try to state what I perceive to be the things we really need so
we can narrow down whether this is the right direction to be going:

1)
- we need a high-performance in-memory cache
- we need that cache to be backed by some sort of persistence for two
reasons
  first, so that cached items aren't lost between server starts
  second so that items bumped off the memory cache can still be
preserved as the assumption is that pulling a cached item off disk is
still faster than regenerating the entire pipeline.  for example, the
most popular 100 items are served in memory, but the rest are on disk.
(and at shutdown, the 100 in-memory ones go to disk).

** is JCS (properly configured) a good way to meet both of these
requirements?

CM: Yes.  A JCS store can be configured to use an MRU store (the test
config provided does just this.) This MRU store is in turn configurable
- number of objects catered for, what type of store (memory etc.) The
swapping to disk based store is handled in the same way as Cocoon
currently does - objects are dropped out of MRU store into diskbased
store. The only difference is that the "disk based" store can in fact be
any of the several stores supported by JCS (remote server, disk, JISP
etc.)

At shutdown, things can be configured to store to disk (both store, and
index.)  The only issue is that in the event of an abnormal shutdown the
index can be lost (this is only when the index is kept in memory of
course - other store types which use pure disk based index storage
wouldn't be effected by this.)
--

2) currently we accomplish both of those transparently with a
transient-store configured to use a persistent-store.  we have some
subsystems which use a transient-store configured _not_ to use
persistence because of application requirements.

** is JCS (properly configured) a good way to meet this requirement?

CM: Yes.  You could very easily configure a separate role for transient
store which would use a different group / region (JCS terms.)  This
region would be configured to use _only_ memory store, with no support
for persistence.  This could be accomplished as is, by changing roles
appropriately, and providing different config in the xconf for the
transient store.
--

3) we have one subsystem which goes direct to the persistent-store right

at shutdown which could just as easily go to the in-memory front-end as
long as the persistence between restarts still happened.

** is JCS (properly configured) a good way to meet this requirement?

CM: Yes.  Again, this could either be written to the default store,
which would go to MRU, and then disk at shutdown, _or_ a different group
/ region could be created and configured which would go straight to
disk, without an in-memory MRU involved.
--

I am not following the details well here about the persistence issue. 
If we don't use the Disk Cache, what other persistent (on disk, survives

restarts) options are there?

CM: As I mentioned before, the only issue which needs more investigation
is abnormal shutdown with an in-memory index, however, this could
theoretically be up to the user to decide - if their application
requires an absolute guarantee of persistence at all times, they could
configure it to use an on-disk index at all times - this would require
no class change, just a change in the CCF.

Hope that answers your questions properly :)  I have a horrible feeling
that my email client won't format this nicely ;)
--

Geoff




>-Original Message-
>From: Unico Hommes [mailto:[EMAIL PROTECTED]
>
>Sent: Saturday, 6 March 2004 3:46 a.m.
>To: [EMAIL PROTECTED]
>Subject: Re: Turning off default MRU store
>
>
>Geoff Howard wrote:
>
> 
>
>>Unico Hommes wrote:
>>
>>   
>>
>>>Sylvain Wallez wrote:
>>>
>>> 
>>>
Unico Hommes wrote:

   

>Unico Hommes wrote:
>
>

RE: JCSStore causes stack overflow?

[Antonio Gallardo]

Hi Corin:

That means JCS is a win-win game to us! Lets define JCS as the default
cache system in the new Cocoon release!

BTW, your mail comes in a weird for to me. As an attachment of another
empty mail with a disclosure notice.

Best Regards,

Antonio Gallardo.

Re: ASF 2.0 license upgrade - how?

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> I think Antonio was about to commit the results of running
> insert_license.pl, but he just disappeared from IRC, he might be having
> connection problems.

Hi I am back!

Yep. My  ISP had problems. I am  back and working on it.

Best Regards,

Antonio Gallardo

Re: Turning off default MRU store

[Geoff Howard]

Corin Moss wrote:

Hi Guys,

I think the thing to remember here is that it's the Disk Cache
implementation that has this behaviour, and that it's very easy to use a
different store type if the user feels it's necessary.  There are other,
"safer" store implementations we can use - the only problem in this case
is that the index is kept in memory (which is what makes it so fast.)
If the user decides that this is inappropriate for them, the change to a
different store type is very easy to make within the config.
I think that moving to a filesystem store would be counter-productive,
as the thing that JCS provides is total flexibility of store type.
Just my thoughts :)
 

Ok, I apologize that I just can't look into this myself right now, but 
let me try to state what I perceive to be the things we really need so 
we can narrow down whether this is the right direction to be going:

1)
- we need a high-performance in-memory cache
- we need that cache to be backed by some sort of persistence for two 
reasons
 first, so that cached items aren't lost between server starts
 second so that items bumped off the memory cache can still be 
preserved as the assumption is that pulling a cached item off disk is 
still faster than regenerating the entire pipeline.  for example, the 
most popular 100 items are served in memory, but the rest are on disk. 
(and at shutdown, the 100 in-memory ones go to disk).

** is JCS (properly configured) a good way to meet both of these 
requirements?

2) currently we accomplish both of those transparently with a 
transient-store configured to use a persistent-store.  we have some 
subsystems which use a transient-store configured _not_ to use 
persistence because of application requirements.

** is JCS (properly configured) a good way to meet this requirement?

3) we have one subsystem which goes direct to the persistent-store right 
at shutdown which could just as easily go to the in-memory front-end as 
long as the persistence between restarts still happened.

** is JCS (properly configured) a good way to meet this requirement?

I am not following the details well here about the persistence issue.  
If we don't use the Disk Cache, what other persistent (on disk, survives 
restarts) options are there? 

Geoff




-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Saturday, 6 March 2004 3:46 a.m.
To: [EMAIL PROTECTED]
Subject: Re: Turning off default MRU store
Geoff Howard wrote:

 

Unico Hommes wrote:

   

Sylvain Wallez wrote:

 

Unico Hommes wrote:

   

Unico Hommes wrote:

 

Corin Moss wrote:

   

Hi Guys,

I might be getting ahead of myself a bit here, but I'm going to
try and turn off the default MRU store, in favour of the JCS
 

 

based persistent store.  I'd like to try some tests on
 

 

performance without the default MRU - has anyone else tried
 

 

anything similar? I've simply set the core store's role to point
 

 

to the JCS store implementation.

 

I guess I already got ahead of you when I renamed
JCSPersistentStore JCSStore just now :-) (And merged it with the
   

 

AbstractJCSStore BTW). It seems to me that JCS is both and it
   

 

could replace all three stores: DefaultStore, TransientStore and
   

 

PersistentStore.

   

I have to add that this is not the whole story. We do actually need
to distinguish between persistent and transient storage. Some
 

 

components explicitly want to persist some data instead of just
 

 

cache it for speed. But as far as caching is concerned I think it
 

 

we can leave it completely up to JCS.
 



Some components are explicitely using the transient-store to keep
data that shouldn't (or cannot) be serialized. But AFAIK, no
   

 

component directly uses the persistent-store except the store
   

itself.
 

To my knowlegde there is one in eventcache block that uses the
PersistentStore to persist some info it needs to recover upon next
 

 

startup.

It does not look to me as though JCS would fit the PersistentStore
role very well. I was thinking that perhaps. We could have JCSStore
 

 

as a replacement for TransientStore and Store roles and use
 

 

FilesystemStore for the PersistentStore role.
 

Wait a minute.  The original issue that brought JCS to the front as
that the persistent store was broken and had license problems.  Are
   

 

you saying that JCS isn't a good candidate for persisting the cached
   

 

info to disk, or that the fact that it by default has an MRU memory
   

 

front-end makes it not map directly to persistent-store role cleanly?

   

IIUC, JCS will always use a memory store in front yes. And it suggests

on the JCS website that the persistence process is not very reliable:

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

"When the disk cache is properly shutdown,

DO NOT REPLY [Bug 22400] - [PATCH] SQLTransformer to optionally preserve case of column names

[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=22400

[PATCH] SQLTransformer to optionally preserve case of column names

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|SQLTransformer to optionally|[PATCH] SQLTransformer to
   |preserve case of column |optionally preserve case of
   |names   |column names

RE: Turning off default MRU store

[Corin Moss]

Hi Guys,

I think the thing to remember here is that it's the Disk Cache
implementation that has this behaviour, and that it's very easy to use a
different store type if the user feels it's necessary.  There are other,
"safer" store implementations we can use - the only problem in this case
is that the index is kept in memory (which is what makes it so fast.)
If the user decides that this is inappropriate for them, the change to a
different store type is very easy to make within the config.

I think that moving to a filesystem store would be counter-productive,
as the thing that JCS provides is total flexibility of store type.

Just my thoughts :)

-Original Message-
From: Unico Hommes [mailto:[EMAIL PROTECTED]
Sent: Saturday, 6 March 2004 3:46 a.m.
To: [EMAIL PROTECTED]
Subject: Re: Turning off default MRU store


Geoff Howard wrote:

> Unico Hommes wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Unico Hommes wrote:
>>>

 Unico Hommes wrote:

>
>
> Corin Moss wrote:
>
>> Hi Guys,
>>
>> I might be getting ahead of myself a bit here, but I'm going to
>> try and turn off the default MRU store, in favour of the JCS
>> based persistent store.  I'd like to try some tests on
>> performance without the default MRU - has anyone else tried
>> anything similar? I've simply set the core store's role to point
>> to the JCS store implementation.
>>
>
> I guess I already got ahead of you when I renamed
> JCSPersistentStore JCSStore just now :-) (And merged it with the
> AbstractJCSStore BTW). It seems to me that JCS is both and it
> could replace all three stores: DefaultStore, TransientStore and
> PersistentStore.
>

 I have to add that this is not the whole story. We do actually need
 to distinguish between persistent and transient storage. Some
 components explicitly want to persist some data instead of just
 cache it for speed. But as far as caching is concerned I think it
 we can leave it completely up to JCS.
>>>
>>>
>>>
>>>
>>>
>>> Some components are explicitely using the transient-store to keep
>>> data that shouldn't (or cannot) be serialized. But AFAIK, no
>>> component directly uses the persistent-store except the store
itself.
>>>
>>
>> To my knowlegde there is one in eventcache block that uses the
>> PersistentStore to persist some info it needs to recover upon next
>> startup.
>>
>> It does not look to me as though JCS would fit the PersistentStore
>> role very well. I was thinking that perhaps. We could have JCSStore
>> as a replacement for TransientStore and Store roles and use
>> FilesystemStore for the PersistentStore role.
>
>
>
> Wait a minute.  The original issue that brought JCS to the front as
> that the persistent store was broken and had license problems.  Are
> you saying that JCS isn't a good candidate for persisting the cached
> info to disk, or that the fact that it by default has an MRU memory
> front-end makes it not map directly to persistent-store role cleanly?
>
IIUC, JCS will always use a memory store in front yes. And it suggests
on the JCS website that the persistence process is not very reliable:

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

"When the disk cache is properly shutdown, the memory index is written
to disk and the value file is defragmented. When the cache starts up,
the disk cache can be configured to read or delete the index file. This
provides an unreliable persistence mechanism."

> The use of persistent store in eventcache shouldn't be a problem with
> JCS as long as at shutdown, it persists everything it has in its MRU
> if it hasn't already.  If there is some problem it would be much
> better to just go back to the old serializing persistence for the
> event cache data because the only benefit to putting it in the store
> is that you more or less guaranteed that the events and cached
> responses would be kept together.


Yes, giving up that feature would be too bad.

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

DO NOT REPLY [Bug 22400] - SQLTransformer to optionally preserve case of column names

[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=22400

SQLTransformer to optionally preserve case of column names

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:50 ---
*** Bug 16710 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 16710] - SQLTransformer.Query.serializeRow forces lower case column names

[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=16710

SQLTransformer.Query.serializeRow forces lower case column names

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:50 ---


*** This bug has been marked as a duplicate of 22400 ***

DO NOT REPLY [Bug 21177] - a crash in the name() function of the xslt, when using SQL transformer

[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=21177

a crash in the name() function of the xslt, when using SQL transformer





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:49 ---
A wild guess from my side is that it is related to bug #25203. That bug also
shows that the XML handling is not quite correct in the SQLTransformer. This
crash can result from the same error in SQLTransformer.

But a test with a recent Xalan would be good though.

DO NOT REPLY [Bug 20736] - JXForms validator rejects null value for numeric field

[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=20736

JXForms validator rejects null value for numeric field





--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:44 ---
They won't be merged into Woody codewise. And there was already the decision to
deprecate JXForms in near future, XMLForms is already. So this bug will probably
get a WONTFIX. Or do you want to apply this patch now yourself, Ugo?

DO NOT REPLY [Bug 20631] - [PATCH] Support for transactions in SQLTransformer

[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=20631

[PATCH] Support for transactions in SQLTransformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:41 ---
25 votes (!) really makes it necessary to set the priority to high.

David, I hope you are still listening. I want to ask you if you can provide this
patch again for the recent 2.1 version (which has changed partly since your
patch date) and provide it in diff form. Daniel's patch (bug #16718) was applied
some time ago. Now your's can be applied as well, we only need an update on it
(at least it would simplify committer's life as we had to get the changes from
your old patch below by hand otherwise).

Doing it additionally for 2.0 is not a must (Daniel's patch was not applied
there) as its development was stopped, but if you want to do this as well, no
one will stop you. We decided to release a last 2.0 release in near future, so
it would not be useless.

BTW, you don't need to attach the complete Java file. And we will not change the
package as we want to avoid duplicate as far as possible.

Thanks for your understanding,

Joerg

DO NOT REPLY [Bug 18116] - VelocityGenerator child elements don't take 'key' attribute

[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=18116

VelocityGenerator  child elements don't take 'key' attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 18116] - VelocityGenerator child elements don't take 'key' attribute

[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=18116

VelocityGenerator  child elements don't take 'key' attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-06 00:15 ---
Less than a year for fixing a documentation bug - we are good ;-)

Fixed in JavaDoc and Xdocs, both in 2.0 and 2.1.

Thanks for reporting,

Joerg

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Pier Fumagalli]

On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:

Tim Larson wrote:

On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:

 Package: org.apache.cocoon.cforms

here I would go "forms" instead. package naming is where the estate 
really is, where class collissions might happen.
I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?
eh, very good question, actually. I spent a few hours discussing with 
Pier about this yesterday over IM. Pier, as usual, sees the very core 
problem and I always miss ;-)
Heh! :-) No, Ste, it's that I only have to shovel more crap than you 
have to on production environments...

What it means is that I'd rather have a simpler (and more 
understandable) environment to code against, rather than a complete but 
complex one, because when shit happens, I'm going to be the one who has 
to bring our LIVE server up-and-running QUICK! :-P

The way the JVM classloading mechanism is designed (well, the code 
verifier actually) is that you cannot have two classes with the same 
name and package in the same classloading hierarchy.

So, for example, suppose you have the following hierarchy:

B
   /
  A
   \
C
where block A depends on block B and C. Now, if B and C expose the 
same class, there is no problem if that is accessed from B or from C 
internally, but as soon as A starts to access it, which one does it 
get?
Perfectly correct... More in details, A will have an instance of the 
Class object from either B or C linked to the class name. For example 
if both B and C expose the class "org.betaversion.MyClass", the C and B 
classloader will both contain an instance of that class associated with 
that name.

When A receives an instance of "org.betaversion.MyClass" the ByteCode 
Verifier will check it against A's classloader instance of the 
"org.betaversion.MyClass" class object, which he got from either B or 
C.

If the instance of the class object A has is different from the one 
that instantiated the object, well, the BCV will throw a 
ClassCastException

(It might be tricky to understand what's an instance of a Class and 
what's an instance of an Object, if someone has some doubts, ask me, 
please... I had to read the JVM specification 3 or 4 times before 
grasping it)

So, in short, it is feasible (IMHO, even if I haven't tried yet) to 
come up with a classloading hierarchy that allows isolation, but only 
when the semantics associated to the class usage are *really* 
isolated.
It is absolutely possible, yes... IN THEORY! :-D

It means that if (in the above example), we could analyze all classes 
accessible by A supplied by B and C (which means all public classes), 
analyze their signatures, come up with a list of all the class 
instances which are "visible" from outside, we can safely see whether 
we can (or not) satisfy our versions tree.

In practice (though) this is quite impossible as 99.9% of the classes 
created are always "public" and therefore accessible from the children 
class loaders...

Note that this seems easy to enforce, but it's really not, especially 
if you get into block versioning!!!

  X.1
 /
B
   /
  A   D
   \ / \
C   E
 \   \
  F   X.2
Now, if A asks for a particular task that B executes, requiring 
version 1 of block X, then asks for another task, executed by C, left 
to D, which handles to E which requires version 2 of X, then you get a 
ClassCastException. No way out!

And debugging this is going to be the biggest pain in the universe!!
Not even debugging... Analyzing the dependancies (although possible) 
will be a nightmare...

So, my suggestion is to create a dependency checker which will tell 
all the potential class collision conflicts, at deploy time (by 
crawling the class space, perform MD5 hashing of classes and identify 
collisions)
You don't even have to have an MD5 :-) Because even if you have the 
SAME EXACT file, if that file is loaded by two different classloaders, 
you won't be able to do a cast operation...

It's a matter of instances of class objects... The instance of the 
class is different, no way you can cast...

So, in short: having to different versions of the same interface in 
memory is possible only if there is always a way for the system to 
differentiate between them. that is: no way to use them both.

Trivial for a few blocks, but very tricky when the number of blocks 
dependencies explodes.
Ok, I see that it MIGHT be a problem... But it will also be an 
incentive. If I (Pier) write a block, and that relies on a set of other 
blocks, and I CANNOT avoid the problem of "old versions", I will be 
forced to "maintain" my block if I want to use new features...

It basically turns a tech

DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly

[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=27484

NPE - Cocoon attempts to resolve input source incorrectly





--- Additional Comments From [EMAIL PROTECTED]  2004-03-05 22:39 ---
This "org" thing was already mentioned somewhere, searching on Cocoon archives
should at least show the thread, don't know if there was a solution.

DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly

[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=27484

NPE - Cocoon attempts to resolve input source incorrectly





--- Additional Comments From [EMAIL PROTECTED]  2004-03-05 22:33 ---
In CompilingClassLoader in the compile method we find that it is attempting to 
compile a Source of "org.apache.excalibur.source.impl.URLSource" for the 
className "org".

Re: Experience with workflow at Hippo Webworks

[Stefano Mazzocchi]

Johan Stuyts wrote:

Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo. 
Below are our experiences.

As people with different levels of experience are interested in workflow 
I will start with a (very) brief introduction to workflow.

Workflow introduction
-
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do 
what) a document (an object) after a writer has asked for a review (at 
which time).

The lists of documents to be reviewed is an example of a pending task 
list for an editor.

Each object type can have its own specific workflow.

The demo workflow
-
The demo we created has a workflow for a basic document type, a web 
page. I have attached a diagram of it.

A document gets created by a writer. The writer is not allowed to 
publish his document directly, he has to ask the editor for review.

The editor can easily review documents because we generate a list of 
documents waiting for review. The editor can click on the document and 
can either approve or disapprove. If the document gets approved it is 
published on the public server.

If the document gets disapproved the writer can not ask for a review 
without editing it first. Editing the document when it has been approved 
will bring the document back to the editing state too. After making his 
changes the user can ask for a review of the new version.

Implementation
--
For the document repository we use Slide. For the workflow engine we 
used OSWorkflow. We connected these two using Slide interceptors.
wow, supercool!! I want it :-)

When a document is created the interceptor checks to see whether a 
workflow already exists. It does this by retrieving the workflow ID from 
a WebDAV property of the document. If it doesn't exist a new workflow is 
created in the workflow store.
Interesting terminology you use here: let me ask you this before we get 
confused: "workflow" is for you an instance of the model or the model 
itself?

When our frontend retrieves the tree of documents, the interceptor will 
retrieve the workflow for each document. 
Seems to be the instance. Ok, careful though, because normally people 
refer to workflow as the "model", not the instance.

Looking at the role of the user 
the interceptor will determine which actions are enabled. The enabled 
actions (including their display text and activation URLs) are set in a 
WebDAV property of the document.

For the generation of the pending task list we used the OSWorkflow query 
API to generate the documents which are in the waiting-for-review state. 
The approve and disapprove actions are passed to the frontend in the 
same way as the commands for a writer.

Not all actions are directly shown in the menu, because the user invokes 
them implicitly. The edit action for example is invoked by the 
interceptor each time the user saves the document.

Issues
--
We encountered issues with both slides and OSWorkflow during the 
implementation.

Before we used Slide, we used the Cocoon repository. The semantics of 
the repository interceptors and the Slide interceptors is not the same. 
With the repository interceptor we were able to add a property to the 
document in postStoreContent(...). In Slide we had to do this in 
preStoreContent(...).
IMHO, makes more sense to add metadata in pre-saving than in 
post-saving. It's way more efficient for clustered environments.

Apart from that the Slide interceptors work very well, but (in the 
version of Slide we used) they get called a lot. A single store of a 
document invoked preStoreContent(...) and postStoreContent(...) multiple 
times.
well, this is a bug then. there should be a way to connect to an atomic 
event for a content store... you might want to bring this up on slide-dev

OSWorkflow performed great too. The only disadvantage was the complexity 
of state machines that can be expressed. As you can see in the attached 
diagram nested states are used. OSWorkflow does not support these.
The more I hear about workflows, the more I think that writing them with 
flow and continuations makes more sense than writing a finite state machine.

Although the attached workflow does not contain parallel states, we 
think it might be needed for some document types. A newsletter for 
example follows the same workflow as the attached one. But parallel to 
this is a mailing workflow for sending it to the newsletter subscribers.

In the mailing workflow the user can send a test email of the current 
version to himself. When he is satisfied he can send the final version 
to the newsletter subscribers. After this, he can neither send a test 
email nor send it to the subscribers.

But what to do if a mistake in the newsletter is found afte

Re: From Woody to CocoonForms

[Andreas Hochsteger]

I thought about the same like you, Ugo.

But Tim has a very valid point here:
Try searching goolge for 'forms' and then for 'cforms'
Ugo Cei wrote:
Marc Portier wrote:

another +1 to 'cforms' over 'forms'


Doesn't the "c" stand for "Cocoon"? If it does, I find it somewhat 
redundant, especially in a package name: org.apache.cocoon.forms == 
org.apache.cocoon.cocoon.forms?

And what if someday we develop a new forms framework, do we call it 
"dforms"? ;-)

I propose to use just "forms" as the block name, "Cocoon Forms" in the 
docs, and do a s/woody/forms/ in the package names and namespaces.

Just MHO,

Ugo

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Ugo Cei]

Stefano Mazzocchi wrote:

So, to sum up, here is my proposal:

  
  Block Title: Cocoon Forms
+1
  Block Name: cforms
+0 (I would prefer just "forms" but "cforms" will do).
  Package: org.apache.cocoon.forms
+1
  Namespace: http://apache.org/cocoon/forms/definition/1.0
+1

	Ugo

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

[Vadim Gritsenko]

Stefano Mazzocchi wrote:

I would do

  http://apache.org/cocoon/cforms/1.0#definition


Stefano, how could you???!!!

   http://apache.org/cocoon/forms/1.0#definition

;-P
Vadim

Re: From Woody to CocoonForms

[Ugo Cei]

Marc Portier wrote:
another +1 to 'cforms' over 'forms'
Doesn't the "c" stand for "Cocoon"? If it does, I find it somewhat 
redundant, especially in a package name: org.apache.cocoon.forms == 
org.apache.cocoon.cocoon.forms?

And what if someday we develop a new forms framework, do we call it 
"dforms"? ;-)

I propose to use just "forms" as the block name, "Cocoon Forms" in the 
docs, and do a s/woody/forms/ in the package names and namespaces.

Just MHO,

	Ugo

Re: Usage of SAXBuffer?

[Christopher Oliver]

Stephan Coboos wrote:

Christopher Oliver wrote:

You could use the JXTemplate generator to do this without Java
programming:

 
 

 

--
Chris
Thank you, Chris. But I need to write my own transformer for several 
reasons. 
Can you explain the other reasons?

So I can't use JXTransformer. My problem is not how to create an 
iteration but how to repeat a bunch of sax events several times within 
a transformer.

One possible solution would be to put the events on a stack. The 
better solution would SAXBufffer be, I hope so.

Therefore I need a short example how to use this class.
Try looking at org.apache.cocoon.woody.transformation.EffectPipe in the 
Woody block.

--
Chris

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Stefano Mazzocchi]

Joerg Heinicke wrote:

On 05.03.2004 19:49, Tim Larson wrote:

 Package: org.apache.cocoon.cforms

here I would go "forms" instead. package naming is where the estate 
really is, where class collissions might happen.


I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?


This was exactly the reason I liked the cforms in the package name more 
than just forms. BTW, why plural (c)forms instead of singular (c)form?
NOTE: the name "cforms" or "forms" doesn't make any different in the 
previous versioning scenario.

It's a completely unrelated problem and having a more distinctive name 
(cforms) is not going to help since the problem emerges violently 
already when you have two different versions of the same block installed 
in a single cocoon instance.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Stefano Mazzocchi]

Tim Larson wrote:

On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:

 Package: org.apache.cocoon.cforms

here I would go "forms" instead. package naming is where the estate 
really is, where class collissions might happen.
I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?
eh, very good question, actually. I spent a few hours discussing with 
Pier about this yesterday over IM. Pier, as usual, sees the very core 
problem and I always miss ;-)

The way the JVM classloading mechanism is designed (well, the code 
verifier actually) is that you cannot have two classes with the same 
name and package in the same classloading hierarchy.

So, for example, suppose you have the following hierarchy:

B
   /
  A
   \
C
where block A depends on block B and C. Now, if B and C expose the same 
class, there is no problem if that is accessed from B or from C 
internally, but as soon as A starts to access it, which one does it get?

So, in short, it is feasible (IMHO, even if I haven't tried yet) to come 
up with a classloading hierarchy that allows isolation, but only when 
the semantics associated to the class usage are *really* isolated.

Note that this seems easy to enforce, but it's really not, especially if 
you get into block versioning!!!

  X.1
 /
B
   /
  A   D
   \ / \
C   E
 \   \
  F   X.2
Now, if A asks for a particular task that B executes, requiring version 
1 of block X, then asks for another task, executed by C, left to D, 
which handles to E which requires version 2 of X, then you get a 
ClassCastException. No way out!

And debugging this is going to be the biggest pain in the universe!!

So, my suggestion is to create a dependency checker which will tell all 
the potential class collision conflicts, at deploy time (by crawling the 
class space, perform MD5 hashing of classes and identify collisions)

So, in short: having to different versions of the same interface in 
memory is possible only if there is always a way for the system to 
differentiate between them. that is: no way to use them both.

Trivial for a few blocks, but very tricky when the number of blocks 
dependencies explodes.

This is the best answer I can give at the moment.

Pier, anything to add here?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

[Stefano Mazzocchi]

Reinhard Pötz wrote:

Marc Portier wrote:

Reinhard Pötz wrote:

Vadim Gritsenko wrote:

Reinhard Pötz wrote:

Tim Larson wrote:


+1 'cforms' instead of just 'forms'


I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?


Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0


sorry for missing the argumentation on keeping the 'forms' here, or is 
this a typo?

  NS Prefix: fd


and similar for binding and templating I presume? we might question if 
reordering the sub-domain and version-no is not more natural then:

xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition
xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding


I like it, but I'm no specialist on those things.
Stefano, IIRC you did some research on namespaces for Cocoon Blocks, WDYT?
I would do

  http://apache.org/cocoon/cforms/1.0#definition

so that in the future there is an algorithmical way to get to the version.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 27484] New: - NPE - Cocoon attempts to resolve input source incorrectly

[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=27484

NPE - Cocoon attempts to resolve input source incorrectly

   Summary: NPE - Cocoon attempts to resolve input source
incorrectly
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Flowscript
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When deploying Cocoon as part of an EAR file under JBoss 3.0.4 Tomcat 4.1.12 
Cocoon gives the following stack trace when returning from a continuaition.  
The problem does not happen under 2.1.3 or if deployed as an expanded EAR.  
See:

 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107574604114201&w=2 

for more info.  

Note that forcing a null return in SourceReaderFactory does not correct the 
problem (which make sense since the script is run up until the continuation is 
invoked).  

Also note that in our case the continuation is returned using an input module 
called from the sitemap as:



where "continuations" is the name for an input module that resolves the 
current continuation to use.

Partial stack trace:

java.lang.NullPointerException 
at org.eclipse.jdt.internal.compiler.parser.Scanner.setSource
(Scanner.java:2979) 
at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:7106) 
at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:4733) 
at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile
(Compiler.java:289) 
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:324) 
at org.tempuri.javacImpl.eclipse.JavaCompilerImpl.compile
(JavaCompilerImpl.java:394) 
at 
org.apache.cocoon.components.flow.javascript.fom.CompilingClassLoader.compile
(CompilingClassLoader.java:374) 
at 
org.apache.cocoon.components.flow.javascript.fom.CompilingClassLoader.findClass
(CompilingClassLoader.java:99) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:289) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:235) 
at org.mozilla.javascript.NativeJavaPackage.getPkgProperty
(NativeJavaPackage.java:181) 
at org.mozilla.javascript.NativeJavaPackage.get(NativeJavaPackage.java:156) 
at org.mozilla.javascript.ScriptRuntime.getProp(ScriptRuntime.java:723) 
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret
(ContinuationInterpreter.java:677) 
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret
(ContinuationInterpreter.java:190) 
at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret
(ContinuationInterpreter.java:138) 
at org.mozilla.javascript.continuations.InterpretedFunctionImpl.call
(InterpretedFunctionImpl.java:121) 
at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) 
at org.mozilla.javascript.ScriptableObject.callMethod
(ScriptableObject.java:1591) 
at 
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.hand
leContinuation(FOM_JavaScriptInterpreter.java:799) 
at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke
(CallFunctionNode.java:150)

Re: Usage of SAXBuffer?

[Stephan Coboos]

Christopher Oliver wrote:

You could use the JXTemplate generator to do this without Java
programming:

 
 

 

--
Chris
Thank you, Chris. But I need to write my own transformer for several 
reasons. So I can't use JXTransformer. My problem is not how to create 
an iteration but how to repeat a bunch of sax events several times 
within a transformer.

One possible solution would be to put the events on a stack. The better 
solution would SAXBufffer be, I hope so.

Therefore I need a short example how to use this class.

Regards

RE: SimpleFormTransformer (was: From Woody to CocoonForms)

[Ralph Goers]

Yes.  

 -Original Message-
From:   Joerg Heinicke [mailto:[EMAIL PROTECTED] 
Sent:   Friday, March 05, 2004 11:49 AM
To: [EMAIL PROTECTED]
Subject:SimpleFormTransformer (was: From Woody to CocoonForms)

On 05.03.2004 16:57, Ralph Goers wrote:

> I am not in favor of having FormValidatorAction and SimpleFormsTransformer
> deprecated.  They are lightweight and do the job they were intended to do.

Until now the discussions about deprecating old form stuff where only 
about the two existing blocks and frameworks XMLForms and JXForms. I 
don't know about SimpleFormTransformer - is Woody/CForms in contrary 
really complex?

Joerg

SimpleFormTransformer (was: From Woody to CocoonForms)

[Joerg Heinicke]

On 05.03.2004 16:57, Ralph Goers wrote:

I am not in favor of having FormValidatorAction and SimpleFormsTransformer
deprecated.  They are lightweight and do the job they were intended to do.
Until now the discussions about deprecating old form stuff where only 
about the two existing blocks and frameworks XMLForms and JXForms. I 
don't know about SimpleFormTransformer - is Woody/CForms in contrary 
really complex?

Joerg

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Joerg Heinicke]

On 05.03.2004 19:49, Tim Larson wrote:

 Package: org.apache.cocoon.cforms

here I would go "forms" instead. package naming is where the estate 
really is, where class collissions might happen.


I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?
This was exactly the reason I liked the cforms in the package name more 
than just forms. BTW, why plural (c)forms instead of singular (c)form?

Joerg

RE: Usage of SAXBuffer?

[Christopher Oliver]

You could use the JXTemplate generator to do this without Java
programming:


  
  
 
  


--
Chris

-Original Message-
From: Stephan Coboos [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 05, 2004 11:15 AM
To: [EMAIL PROTECTED]
Subject: Usage of SAXBuffer?

Hello,

I want to write my own transformer which iterates over a element and 
repeates the content several times. For example:


I'm the content


The content "I'm the content" should be repeated 3 times, like
this:

I'm the content
I'm the content
I'm the content

Can I use the class org.apache.cocoon.xml.SAXBuffer to do that?

Can you give me a short example, how to use this class within a
transformer?

Thank you.

Regards
Stephan

Re: Lastest from CVS 2.1.5-dev broken?

[Joerg Heinicke]

On 05.03.2004 19:23, Oscar Picasso wrote:

I had some Exceptions on startup but they seem to relate to something in the
scratchpad: 'cache.ccf'. What is this?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27385

There are also a few threads in the archives, have a look for JISP and JCS.

Joerg

Usage of SAXBuffer?

[Stephan Coboos]

Hello,

I want to write my own transformer which iterates over a element and 
repeates the content several times. For example:


   I'm the content

The content "I'm the content" should be repeated 3 times, like this:

   I'm the content
   I'm the content
   I'm the content
Can I use the class org.apache.cocoon.xml.SAXBuffer to do that?

Can you give me a short example, how to use this class within a transformer?

Thank you.

Regards
Stephan

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Tim Larson]

On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
> Marc Portier wrote:
> 
> >another argument for having [cforms] from my side was that you could 
> >never confuse it with the known english word 'form' that could mean an 
> >HTML form, a paper-form, a whatever formalism or whatnot... in 
> >discussions on these lists, and thus possibly introducing confusion that 
> >can be avoided
> 
> I find myself selfdebating here.
> 
> I'm 60% on forms "everywhere" and 40% on +1 the proposal.
> 
> the reason for using "forms" everywhere is that I want people to fight 
> for having their features in, instead of going their own way with 
> another block.

Understood, and I agree with the motivation.

> Scratchpad blocks are awesome as a way to cover new ground and propose 
> new functionality, but once we start supporting them officially, well, 
> the things change.
> 
> This is why the name change:
> 
>  - woody was a proposal
>  - Cocoon Forms are *the way* cocoon is going to handle forms from now on
> 
> in a few years, there might be nothing left from woody in Cocoon Forms.
> 
> Now, as I was explaining in IRC today, the scenario I want to avoid is 
> people coming up with, say "sforms" or "cform++" or "cform#" and branch off.
> 
> This is my *only* concern.
> 
> I would go "forms" all the way, in everything: namespaces and package 
> names... but Marc is right: "form" is too general as a term. We could do 
> it with sitemap or flowscript because they were descriptive yet special 
> enough. Forms clearly not descriptive enough.

My main concern is about support and searching. 'Form' does not clarify
which major version is being refered to so it could be hard to quickly
find help for the right major version, since people are notorious for
mentioning the package but not the version in their emails.

> So, let's go over the proposal again:
> 
>   Block Title: Cocoon Forms, or Cocoon Forms 1.0
> 
> +1 for Cocoon Forms (no need to mention the version now)

+1 As agreed previously.

>   Block Name: cforms
> 
> +1, I would like forms better but we need to state cforms somewhere

+1 cforms block solves the support/search issue mentioned above.

>   Package: org.apache.cocoon.cforms
> 
> here I would go "forms" instead. package naming is where the estate 
> really is, where class collissions might happen.

I understand how this seems like a good place for the battleground,
but to introduce a new winner it looks like this would force us to
break code compiled against the previous major version because we
would be stealing the class and interface names for the new version.
Does the new block system somehow solve this problem like via
classloaders or something else?

>   Namespace: http://apache.org/cocoon/forms/definition/1.0
> 
> +1

+1

>   NS Prefix: fd
> 
> +0, doesn't really matter.

+0 sounds fine, not much opinion.

> So, to sum up, here is my proposal:
> 
>   
>   Block Title: Cocoon Forms
>   Block Name: cforms
>   Package: org.apache.cocoon.forms
>   Namespace: http://apache.org/cocoon/forms/definition/1.0
>   
> 
> -- 
> Stefano.

--Tim Larson

Re: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

[Sylvain Wallez]

Reinhard Pötz wrote:

Marc Portier wrote:

Reinhard Pötz wrote:

Vadim Gritsenko wrote:

Reinhard Pötz wrote:

Tim Larson wrote:


+1 'cforms' instead of just 'forms'


I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?


Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0


sorry for missing the argumentation on keeping the 'forms' here, or 
is this a typo?

  NS Prefix: fd


and similar for binding and templating I presume? we might question 
if reordering the sub-domain and version-no is not more natural then:

xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition
xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding


I like it, but I'm no specialist on those things.


I think we should keep the version number at the end. What if, in the 
lifetime of Cocoon forms 1.0 (the general design of it), a new binding 
approach emerges that leads us to use another namespace?

Will it be http://apache.org/cocoon/cforms/1.0/binding/1.1? Looks ugly ;-)

It should be http://apache.org/cocoon/cforms/binding/1.1, that will work 
with http://apache.org/cocoon/forms/definition/1.0.

I'm still undecided however about the use of "forms" or "cforms" in the 
namespace (had no time for IRC today - sorry). Won't it be strange to 
have ".../forms/.../1.0" use classes in the "cforms" package and 
".../forms/.../2.0" use classes in the "zforms" package? Don't know. 
"forms" may be good after all to enforce that there can be only one 
official form framework at a given time.

BTW, good to see you back, Marc!

Sylvain

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

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Stefano Mazzocchi]

Marc Portier wrote:

another argument for having [cforms] from my side was that you could 
never confuse it with the known english word 'form' that could mean an 
HTML form, a paper-form, a whatever formalism or whatnot... in 
discussions on these lists, and thus possibly introducing confusion that 
can be avoided
I find myself selfdebating here.

I'm 60% on forms "everywhere" and 40% on +1 the proposal.

the reason for using "forms" everywhere is that I want people to fight 
for having their features in, instead of going their own way with 
another block.

Scratchpad blocks are awesome as a way to cover new ground and propose 
new functionality, but once we start supporting them officially, well, 
the things change.

This is why the name change:

 - woody was a proposal
 - Cocoon Forms are *the way* cocoon is going to handle forms from now on
in a few years, there might be nothing left from woody in Cocoon Forms.

Now, as I was explaining in IRC today, the scenario I want to avoid is 
people coming up with, say "sforms" or "cform++" or "cform#" and branch off.

This is my *only* concern.

I would go "forms" all the way, in everything: namespaces and package 
names... but Marc is right: "form" is too general as a term. We could do 
it with sitemap or flowscript because they were descriptive yet special 
enough. Forms clearly not descriptive enough.

So, let's go over the proposal again:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0

+1 for Cocoon Forms (no need to mention the version now)

  Block Name: cforms

+1, I would like forms better but we need to state cforms somewhere

  Package: org.apache.cocoon.cforms

here I would go "forms" instead. package naming is where the estate 
really is, where class collissions might happen.

  Namespace: http://apache.org/cocoon/forms/definition/1.0

+1

  NS Prefix: fd

+0, doesn't really matter.

So, to sum up, here is my proposal:

  
  Block Title: Cocoon Forms
  Block Name: cforms
  Package: org.apache.cocoon.forms
  Namespace: http://apache.org/cocoon/forms/definition/1.0
  
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Lastest from CVS 2.1.5-dev broken?

[Oscar Picasso]

--- Oscar Picasso <[EMAIL PROTECTED]> wrote:
> > >Hi,
> > This should have been fixed with a commit about three hours ago. Did you 
> > update after that?
> 
> No before. I am going to try it again now.
> 
> Oscar
> 

Works fine now with the latest from cvs.

I had some Exceptions on startup but they seem to relate to something in the
scratchpad: 'cache.ccf'. What is this?

The Exceptions:

13:09:09,387 ERROR [IndexedDiskCache] Failure initializing for fileName:
groupIdCache and root directory: /www/cocoon/webapps/cocoon/indexed-disk-cache
java.io.FileNotFoundException:
/www/cocoon/webapps/cocoon/indexed-disk-cache/groupIdCache.data (No such file
or directory)

13:09:09,892 ERROR [IndexedDiskCache] Failure initializing for fileName:
indexedRegion3 and root directory:
/www/cocoon/webapps/cocoon/indexed-disk-cache
java.io.FileNotFoundException:
/www/cocoon/webapps/cocoon/indexed-disk-cache/indexedRegion3.data (No such file
or directory)

13:09:10,177 ERROR [IndexedDiskCache] Failure initializing for fileName:
indexedRegion2 and root directory:
/www/cocoon/webapps/cocoon/indexed-disk-cache
java.io.FileNotFoundException:
/www/cocoon/webapps/cocoon/indexed-disk-cache/indexedRegion2.data (No such file
or directory)

13:09:10,339 ERROR [IndexedDiskCache] Failure initializing for fileName:
indexedRegion1 and root directory:
/www/cocoon/webapps/cocoon/indexed-disk-cache
java.io.FileNotFoundException:
/www/cocoon/webapps/cocoon/indexed-disk-cache/indexedRegion1.data (No such file
or directory)


__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

RE: [portal] JSR168 portlets problems under PortalEngine

[Carsten Ziegeler]

Michal Durdina wrote: 
> 
> Hi,
> I found some problems while running jakarta-pluto testsuite 
> under CocoonPortalEngine. I would like to report them and 
> offer help if needed.
> 
Great, really appreciated!

> 1. test2.jsp: Call to 
> portalContext.getSupportedWindowStates() returns null.
> 
I fixed this (hopefully) yesterday morning in the CVS.

> 2. test2.jsp: Call to renderRequest.getParameter("testName") 
> returns null after 2.nd and every other render() was called. 
> Portlet container should preserve request parameters sent 
> upon 1.st request for every subsequent call of render() in 
> the portlet which was not target of the subsequent client 
> request (JSR-168spec chap. 11.1.1 §3). But jakarta-pluto is 
> also doing this, so it's not exactly cocoon problem. 
> 
Did you test the latest pluto version?

> 3. test3.jsp: Submit to url created by 
> renderResponse.createRenderURL(); 
> url.setWindowState(WindowState.MAXIMIZED); changes correctly 
> return value of renderRequest.getWindowState() to 
> "maximized", but the portlet window actually does not 
> maximize. By contrast when submit to url with 
> WindowState.MINIMIZED is executed, the portlet windows 
> minimizes but stays minimized forever - I could not get it to 
> normal size by clicking window icons.
> 
> 4. test4.jsp: Simmilar to point 2. but at this time 
> parameters set by _action_ are not preserved. When testing in 
> jakarta-pluto, they are.
> 
> My testing env:
> cocoon-portal block build from CVS (04.march.2003) 
> jakarta-testuite built from CVS (04.march.2003)
> 
Thanks for reporting this! I think the best way is if you file bugs
into bugzilla. Please enter a bug to the Cocoon bugs if the
problem is only with the Cocoon portal and to Pluto's bug list
if the bug is in Pluto as well.

I will try to update the version of Pluto used in Cocoon to the
latest version in the next days and then have a look at the bugs
you described.

Many thanks!

Carsten

Re: [RT] Cocoon Input Model

[Daniel Fagerstrom]

Alan wrote:
* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-25 21:53]:

XML centric view on input
-
The most important part is not a code change but rather a design 
principle: Input handling is controlled from flowscripts, the flowscript 
typically adapt various input sources to XML (DOM), possibly by using 
pipelines described in the sitemap, it can validate the XML wrt to some 
schema, and it adapts XML to various output and storage formats, 
(possibly by using a pipeline). (If you are extremely unhappy about 
flowscripts, you can replace the mentioned flowscripts with your 
favourite script or programming language ;-) IMHO we should focus on 
flowscripts however).


Might flowscript become less important if input pipelines where brought into
play?
Not necesarily, it is more a design pattern that can be implemented e.g. 
in terms of processPipelineTo[...]


You might have a validator element in the sitemap. If the document
validates accoriding to the validator the pipeline continues, if it fails,
an error pipeline executes that has validator error message output as a
starting point.
You don't need a new kind of sitemap component for that. You can 
implement the validator as a transformer, that throws some kind of 
InvalidXMLException when it fails, then you can register this exception 
in the configuration of the exception selector, and produce the 
appropriate error message output in the map:handle-error section.

Once data is valid, you would then multiplex it into the various storage
devices, or XML consumers.
Once all the data is consumed, you fire off your output pipeline.

What little flow script I've played with, I'm usually just messing with
request parameters. If I could express this as a sitemap input pipeline, I
wouldn't bother.
You use them for connecting to back end and for multi page flow logic also.

A bidirectional mapping between XML and a relational DB would be usefull.


I offered a unidirectional mapping in my previous post. Now that I think of
it, that is the big difference between what I have in mind and what I
normally see.


Data comes out of a RDBMS easily using SQL, a generator turns that into
XML, you then transform it to output. I've never seen the need for
bi-directional because for one direction at least, there is a perfect way
to preform the mapping. Express your desires in SQL. It is *always* a
table and therefore has an obvious representation in XML.

A bi-directional mapping will always produce a table as output anyway.
No, if you have "deeper" XML document you need to map it to several 
tables and relations between them.

The trick is not getting the information out. Most RDBMS are SQL
databases and SQL is a *query* lanaguge.
Most people try to describe a bi-directional mapping and expect some
reward for this touble in (output) query generation. I'd rather describe
the database schema in an XML document, that is describe how I want the
data to go into the database, not how the database maps to an XML
document. There is a difference here.
A common situation in our applications, and I would assume others, is 
that we have lots of customer data in an RDBMS and that we want to store 
some user input from our webapp as well. We always transform the user 
input to XML, so it would of course be much more convinient to store the 
user input in an XMLDB. But then we need to combine the user input with 
what allready is in the RDBMS, so it would not work well to store it in 
another DB. We therefore need a way to store XML in a RDBMS. Currently 
we do that by writting one XML->RDBMS mapping and one RDBMS->XML for 
each XML schema. It would be better to combine it in one mapping.

Components that store and read XML data from repositories would be usefull
as well.


MomentoSource!


CForms should use typed DOM as "form model"
---


I also believe that making CForms use typed XML as data storage is 
important. This obviously require some changes, among other things the 
widget objects need to be split into a control part and a storage part, 
XML data types need support. I will return with a detailed proposal in 
the near future (hopefully ;)). I also hope to get some feedback from 
the people involved in CForms development.


Typed DOM? Confused. Concerned that it might become to grand a scheme. 

I much perfer pipelines to fiddling with nodes.
See answer to Guido


Access to the input stream in all environments?
---


We still have the open question about in which environment the input 
stream should be available.
See http://marc.theaimsgroup.com/?t=10402950241&r=1&w=2 and 
http://marc.theaimsgroup.com/?t=10413429892&r=1&w=2.


New sitemap constructions?
--


It can have a destination parameter where you can use a 
modifyable so

Re: [RT] Cocoon Input Model

[Daniel Fagerstrom]

Alan wrote:

* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-25 15:49]:


Why Cocoon rocks for publishing
---
Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and 
the sitemap. Here we will discuss the first two.

If you have N different input formats and M output formats you need N*M 
converers for converting from every input format to every output format. 
This complexity can be reduced to N+M by finding a standard format...


Having a common format (XML) also makes it worthwhile to write tools 
that use that format booth as input and output (e.g. XSLT), and we can 
use the pipes and filter pattern to build complex transformations in 
terms of smaller specialized, reusable filters.

Dataflow in (web)apps
-


and for (web)apps:


[Input format (user) -> Output format (storage)] -> webapp -> [Input 
format (storage) -> Output format]


This is how I've built by LAMP applications. The first thing is to develop a
database. Then everything goes into the database before it comes back out.
Even if the application only keeps session data, I build a database. It is
a matter of course.
What other ways are there of handing data? Does anyone keep things in
memory, for simply regurgiate the input in their applications?
If so, then there are two pipeline designs, a input / output pipeline pair
and a pass-through pipeline. 


As we can see publishing has one conversion step and (web)apps has two. 
In [1] I talked about input and output pipelines for the two conversion 
steps.


I'd like to expand on this, currently Cocoon treats storage as a filter.
Things like the SQLTransformer filter streams to store data then onward to
a serializer.
What you are proposing is a pipeline that that terminates not at a
serializer, but at something else, that somehow stores the XML. Then it
kicks off a new pipeline that terminates at a serializer.
Yes, that can either be done in flowscript by something like 
processPipelineTo[...], something like 
processPipelineToModifyableSource(pipe, source, args). ANother 
possibility is a new store sitemap component, but as you know by now, 
new sitemap components is a quite controversial subject ;)

To my mind, rather than have this parameter things in the site map, I'd much
rather have everything kept as XML.
Session information, for exmaple. I am going to use Momento to keep a
session document, and then skip that name/value pair nonsense. 
That's the idea, session document sounds like a good name.

Somewhere in my CForms pipelines, I transform input into an XUpdate
statement and build a sub document in a Momento document. Then I can
aggregate or cinclude that session document.

Comparing input and output pipelines, the input handling have one main 
source of extra complexity: we cannot trust user input. We need to check 
that the input is correct and take different action dependent on that, 
so as a consequence control structure becomes more complicated when we 
have user input.


A further reason for detailed control of user input is that while the output
tend go from strongly typed data (db:s, Java etc) to loosely typed data; in
presentation most things are strings. Input tend to have the opposite
requirement, from strings to typed data.


Okay, here is the strongly typed part of it, my apologies, I understand now.

Strongly typed data, but first...

Your solution is nice, except that it your N+M is missing something now.
There are N different input formats, M different output formats, and of
course, S different storage formats.
The general idea is that sources and modifiable sources describe places. 
A generator reads a certain format from a source (place) and converts it 
to XML. A serializer converts from XML to a specified format that in 
turn could be fed into a modifiable source (a place). So the output and 
the storage format are the same, but we have I+M+N+S, where I, S are the 
number of input sources and outpu´t source respectively, instead of 
I*M*N*S if we where to write components that go from input source to 
output source in one step.

Consider a e-mail account user registration form, first page they tell us
who they are and choose a password. Second page, we ask them to choose
which junk newsletters they want to recieve.
When the information arrives and becomes XML. Now maybe I want to put the
XML in three different storage areas. Say I want to store the username and
password in an LDAP directory, the user's profile and such in an
relational database, and the fact that the user is now on the second page
of the registration wizzard as session information.
I think it is easy enough to validate and construct strongly typed data once
the input is an XML format. You can use XML Schema, Relax NG, and such to
validate information in the pipeline, then transform it to XUpdate or
ebXML, or SQ

Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]

[Daniel Fagerstrom]

Alan wrote:
* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-23 15:21]:

XSLT



A MomentoSource would also give a good way to use Momento together with 
XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of 
sources somewhat, let me explain:


The Source interface provides a getInputStream method, in Cocoon some 
Sources implements org.apache.excalibur.xml.sax.XMLizable that provides 
a toSAX method as well. SAX or Streams are probably not the most 
efficient way to communicate with an XML db, so to make the pseudo 
protocol idea usable together with Momento, we should provide a way to 
get a DOM structure from a pseudo protocol. This could be done by 
introducing a new interface:


interface DOMizable {
  org.w3c.domNode getNode();
}


Momento, with Cocoon in mind, lends itself to streaming.

Momento would readily support a read-only W3 DOM, but a read write
W3 DOM is quite ugly.

W3 DOM lets you to create inconsistant documents, with is not in
keeping with the C in ACID. (Examples if you want them.) There
is no way to specify the start and end of an atomic transcation
through the DOM API.

Momento uses XUpdate since one can specify a set of modifications,
and Momento can process those modifications as an atomic
transcation. XUpdate expresses all document modifications, and
does so declaratively. Momento can then make logic of you
intentions.
In a pipeline, XML input can be transformed into XUpdate
statement. I suppose one could an XUpdate using JXTemplate from
Flow as well.
XUpdate is really the method of choice for updating Momento.
Both XUpdate and SAX input are a good way to get data into
Momento.
I don't know if you and I talking about the same thing here, but
the sight of org.w3c.domNode leaves me cold. It is a nice
in-memory interface, but a poor interface for persistence.
If W3 DOM were the way to modify a Momento document, the
application developer would have to be prepared to catch all
kinda hel.., er, exceptions, since there are a bunch of stupid
things that Momento won't allow.
I only talked about read only access of DOM documents from XSLT, don't 
worry ;)



or something similar. If the MomentoSource implements DOMizable, we have 
direct access to nodes in the XML db.


Now we are prepared to connect Momento to XSLT. In Cocoon we can use 
Saxon through the org.apache.cocoon.transformation.TraxTransformer, you 
just need to change cocoon.xconf a little bit to use Saxon instead of 
Xalan. There is also a TraxGenerator in the scratchpad that could be 
used with some small modifications.


Momento connects to XSLT using a Saxon NodeInfo interface. It could
connect to Xalan just as easily (through read-only W3 DOM?).
Yes, that the idea. It can connect to Saxon through read only DOM as 
well, don't know if there are any drawbacks with this though.

I would guess that Momento mainly would be accessed through the document 
function in XSLT and XQuery. Saxon use JAXP 1.1 as external API to the 
transformerand the URLs in the document functions are resolved by using 
an implementation of javax.xml.transform.URIResolver that is provided by 
the TraxTransformer.


The above is somewhat confusing for me. Momento does support the
JAXP API. XUpdate is implemented as a SAX filter. It seems like
Momento would work nicely in as a source, sink, or filter for
SAX events.

I've imagined that a pipeline would start with a Momento
document and an XSLT trasform or XQuery query.

Something along these lines:


  
   xslt="index-document.xslt"/>
  
  


(It is easier for me to express myself as a Cocoon user.)
I rather propose:


  
  
  

The idea is that the xslt generator can be used with any source. For 
this to be efficient with Momento we must organize so that the XSLT 
processor can access momento as a read-only DOM. This will not happen 
today in Cocoon. So what I describe is how to extend the involved 
mechanisms in Cocoon so that Momento get DOM as input.

This is done by creating a new interface, let us call it 
ReadOnlyDOMizable to avoid confusion ;) so that we can check if a 
source, (e.g. the Momento source), can return a DOM. We also need to 
extend the URIResolver in the XSLT processor implementation so that it 
returns a DOMSource if the input source implements ReadOnlyDOMizable, 
SAXSource, if the input source implements XMLizable and StreamSource 
othewise. That is all.


The implementation of the URIResolver that is used is 
org.apache.excalibur.xml.xslt.XSLTProcessorImpl in its current 
incarnation it uses the exclaibur source resolver to get the source and 
then it returns a javax.xml.transform.stream.StreamSource. For use with 
Momento we need an implemetation of URIResolver that checks if the the 
source is DOMIzable and in that case returns a 
javax.xml.transform.dom.DOMS

Re: [RT] Cocoon Input Model

[Daniel Fagerstrom]

Sorry for dissapearing after having started this discussion.

Guido Casper wrote:
Daniel Fagerstrom wrote:

So a pipeline for input handling could look like:

g -> t* -> store -> act -> [select] -> g -> t* -> s.


I'm still not convinced by this symmetry thing :-)

The requirements for inbound data flow seems to be too different from
those of outbound data flow.
For outbound data flow everything is converted to a string which is
quite easy and nicely supported by XML's weakly typed nature (IMO one
major reason for XMLs power and success) and a powerful transformation
language.
For inbound data flow (as you already mentioned) you need strongly typed
data which requires parsing, validation and error handling. I do see
value in putting this data - once grabbed and converted by the forms
framework - into some sort fo pipeline. What I'm unsure about is if
these pipelines will be of similar power as weakly typed pipelines. I
believe Cocoon's pipelines achieve this level of component reusability
because of its weakly typed (and therefore loosely coupled) nature.
Now IIUC you suggest a pipelining architecture for inbound data flow
with a DOM-like data model.
I guess I was a little bit unclear. The typed DOM is only for storing
data in the application. The inbound dataflow is an ordinary Cocoon
pipeline, (SAX, untyped). There might be cases where one would like to
use validation and type info for the inbound data, but I think that
should be done within the pipeline component, not in the communication
between them.
  --- O ---

Steping back a little bit, the main point with my RT was to discuss
design patterns for webapps (or more generally Cocoon based applications
in all supported environments), rather than any sitemap extensions or
the like. All that I proposed can be done within the current Cocoon, I
am not proposing any new mechanisms, (although some stuff possibly could
be done in a more convinient way with new sitemap constructs).
So, a webapp consist of a controller for multi page flow or workflow
(flowscripts). In each step in the flow input is read, an internal state
is updated and output is produced. We all agree about that output
production should be XML based. My main message is that it is a good
idea to use XML for the inbound dataflow and at least to a part as a
storage to.
For the input part this can be done by calling a pipeline with the
processPipelineTo[...] function in flowscripts. The pipeline typically
starts with a stream or request generator or any generator that reads
from a module source connected to an input stream or something similar.
The state consist typically of a backend (DB, EJB etc) and some session
state (session attributes, flowscript variables). For form handling it
is a good design pattern to store input data in a "form model" instead
of writing dirrectly to the backend. Especially if the backend is of
transactional nature. This pattern is used in CForms. The form model is
a (typically typed) data structure where you gather the input before
writing it to the backend. In update operations, the form model is also
loaded with data from the backend before it is "edited" through the web gui.
What I propose is that the "form model" idea is not only usable in
CForms based form handling but in other kinds of webapps as well. So it
would be practical if the utilities for handling some appropriate typed
datastructure was made available outside CForms. Thus the mechanisms for
loading data (XML, Java beans, DB etc) into the store and saving from it
could be reused in other contexts also.
To work well with the rest of Cocoon, XML seem to be the most practical
choise.
Since AFAIK there is no standard DOM-like data model/API carrying 
strongly typed data we would have to come up with our own and I feel it 
might eventual look similar to the Woody widget hierarchy.
You are AFAIK right in that there are no standard API for accessing type
info or detailed validation info. There is a standard:
http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/ for checking 
what element you can add on a point in a tree and a note 
http://www.w3.org/TR/2002/NOTE-DOM-Level-3-AS-20020725/ on accessing 
schema info. Both are IMO overkill for our current needs. What we need 
is adding a schema to a DOM, perform a validation of the DOM, ask a text 
node or attribute for what shema data type it has, if it is valid and 
geting it content in term of a Java object.

So even if we would need some properitary enhancments, we can still use 
DOM core, events, XMLSchema, Relax-NG etc, and implementations of them. 
The data type part of the different schema languages is desiged just for 
creating the strong type system for XML that is needed for dewscribing 
data to/from databases, programs etc.

My point is actually that the storage aspect of the widget hierarchy 
have so many similaritites with typed XML that it seem to be a masive 
re-invention of the wheel to have an own propitary solution with a

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[JD Daniels]

Geoff Howard wrote:

[EMAIL PROTECTED] wrote:

Don't know if my vote counts, just in case: +1

Helma
 

Technically, the "vote" of a non-committer isn't binding, but your 
opinion (and anyone like you) is important and definitely "counts".  
Always feel free to pipe in.

Geoff


+1

I have been eagerly watching all morning :)

DO NOT REPLY [Bug 27456] - [PATCH] BetwixtTransformer output twice the startDocument. Fix.

[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=27456

[PATCH] BetwixtTransformer output twice the startDocument. Fix.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-05 18:00 ---
Tested on 'cocoon-2.1.5-dev' build.

[portal] JSR168 portlets problems under PortalEngine

[DURDINA Michal]

Hi,
I found some problems while running jakarta-pluto testsuite under CocoonPortalEngine. 
I would like to report them and offer help if needed.

1. test2.jsp: Call to portalContext.getSupportedWindowStates() returns null.

2. test2.jsp: Call to renderRequest.getParameter("testName") returns null after 2.nd 
and every other render() was called. Portlet container should preserve request 
parameters sent upon 1.st request for every subsequent call of render() in the portlet 
which was not target of the subsequent client request (JSR-168spec chap. 11.1.1 §3). 
But jakarta-pluto is also doing this, so it's not exactly cocoon problem. 

3. test3.jsp: Submit to url created by renderResponse.createRenderURL(); 
url.setWindowState(WindowState.MAXIMIZED); changes correctly return value of 
renderRequest.getWindowState() to "maximized", but the portlet window actually does 
not maximize. By contrast when submit to url with WindowState.MINIMIZED is executed, 
the portlet windows minimizes but stays minimized forever - I could not get it to 
normal size by clicking window icons.

4. test4.jsp: Simmilar to point 2. but at this time parameters set by _action_ are not 
preserved. When testing in jakarta-pluto, they are.

My testing env:
cocoon-portal block build from CVS (04.march.2003)
jakarta-testuite built from CVS (04.march.2003)

Michal

Re: Lastest from CVS 2.1.5-dev broken?

[Oscar Picasso]

> >Hi,
> This should have been fixed with a commit about three hours ago. Did you 
> update after that?

No before. I am going to try it again now.

Oscar

__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: Lastest from CVS 2.1.5-dev broken?

[Unico Hommes]

Oscar Picasso wrote:

Hi,

I just made a 'cocoon-2.1.5-dev' build from CVS. But on install I get a
statckoverflow.
I tried an install on tomcat-5.0.19 and jboss 3.2.3 and got the same errors.

I also built without the xmldb block but without success.

Any idea?
 

This should have been fixed with a commit about three hours ago. Did you 
update after that?

Unico

Lastest from CVS 2.1.5-dev broken?

[Oscar Picasso]

Hi,

I just made a 'cocoon-2.1.5-dev' build from CVS. But on install I get a
statckoverflow.

I tried an install on tomcat-5.0.19 and jboss 3.2.3 and got the same errors.

I also built without the xmldb block but without success.

Any idea?

Oscar

Here you can find the log files:

http://pages.infinit.net/opicasso/logs-stackoverflow/localhost_log.2004-03-05.txt

http://pages.infinit.net/opicasso/logs-stackoverflow/catalina.out


__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)

[Reinhard Pötz]

Marc Portier wrote:

Reinhard Pötz wrote:

Vadim Gritsenko wrote:

Reinhard Pötz wrote:

Tim Larson wrote:

+1 'cforms' instead of just 'forms'


I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?


Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0

sorry for missing the argumentation on keeping the 'forms' here, or is 
this a typo?

  NS Prefix: fd

and similar for binding and templating I presume? we might question if 
reordering the sub-domain and version-no is not more natural then:

xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition
xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding
I like it, but I'm no specialist on those things.
Stefano, IIRC you did some research on namespaces for Cocoon Blocks, WDYT?
--
Reinhard

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Marc Portier]

Vadim Gritsenko wrote:

Joerg Heinicke wrote:

Marc Portier  outerthought.org> writes:

 

Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

 Block Title: Cocoon Forms, or Cocoon Forms 1.0
 Block Name: cforms
 Package: org.apache.cocoon.cforms
 Namespace: http://apache.org/cocoon/forms/definition/1.0
  
sorry for missing the argumentation on keeping the 'forms' here, or 
is this a typo?
  


AFAIU it this is by intention, no typo. It means the implementation of 
a new
 

Yes, no typo. Cocoon Forms 1.0 is the one and only form framework for 
Cocoon at the moment. Thus namespace is ...cocoon/forms/.../1.0 Once we 
have new-kid-on-the-block replacement for the Cocoon Forms 1.0, it will 
be named Cocoon Forms 2.0 and have namespace .../cocoon/forms/.../2.0

thx for clarifying

(btw: any takers for my other remark on the order of version-number and 
cforms-subdomain?)


form framework can happen in a parallel block, but the namespace 
always points
to *the* form framework. For a new framework accepted as replacement 
for Woody
later on the namespace will just change to 2.0.

+1 from me for the proposal (no IRC possible from here)

Joerg



Vadim

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Vadim Gritsenko]

Joerg Heinicke wrote:

Marc Portier  outerthought.org> writes:

 

Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

 Block Title: Cocoon Forms, or Cocoon Forms 1.0
 Block Name: cforms
 Package: org.apache.cocoon.cforms
 Namespace: http://apache.org/cocoon/forms/definition/1.0
   

sorry for missing the argumentation on keeping the 'forms' here, or is 
this a typo?
   

AFAIU it this is by intention, no typo. It means the implementation of a new
 

Yes, no typo. Cocoon Forms 1.0 is the one and only form framework for 
Cocoon at the moment. Thus namespace is ...cocoon/forms/.../1.0 Once we 
have new-kid-on-the-block replacement for the Cocoon Forms 1.0, it will 
be named Cocoon Forms 2.0 and have namespace .../cocoon/forms/.../2.0


form framework can happen in a parallel block, but the namespace always points
to *the* form framework. For a new framework accepted as replacement for Woody
later on the namespace will just change to 2.0.
+1 from me for the proposal (no IRC possible from here)

Joerg



Vadim

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

[Marc Portier]

Joerg Heinicke wrote:

Vadim Gritsenko  reverycodes.com> writes:




  
  


  
  


I also tend to prefer this approach - same reasoning with ambiguity of 
unique attribute.


Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is
outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though
it is executed also at on-bind event.
yes, but do you find that surprising?
(in fact all of the on-bind is implicit on-insert as well)
Maybe a third alternative helps for that:


  

  
  



  

And a fourth one is to specify values used for uniqueness independent on binding:


  



  
  




  

I used wb:element because I had no name in mind. It also must be clear if you
refer to path (bean or XML) or to id (form model widget). From the XML this is
very similar to Antonio's original proposal and current implementation, but
there is the important difference that there does *not* happen any binding on
wb:unique-row and children. Therefore it's probably clearer than the other
proposals but more verbose.
WDYT?

see my question about 'suprise' above:
I don't think the cost in verbosity is gained by clarity here?
I think replacing wb:unique-row with wb:identity does a far better job 
at adding clarity.

IMHO the behaviour of what happens on the on-bind event is more related 
to the 'strategy' of the repeater as discussed here:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107062679414114&w=2

my proposal would be to mix-in the @strategy and have the docos 
introduce the clarity on what happens in 'on-bind'

wdyt?

Joerg

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

DO NOT REPLY [Bug 27188] - CocoonPortlet default-encoding

[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=27188

CocoonPortlet default-encoding





--- Additional Comments From [EMAIL PROTECTED]  2004-03-05 16:44 ---
Created an attachment (id=10677)
Same patch but for new location of CocoonPortlet.java in portal-block

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Joerg Heinicke]

Marc Portier  outerthought.org> writes:

> >> Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
> >> little chat on IRC and agreed on the following:
> >>
> >>   Block Title: Cocoon Forms, or Cocoon Forms 1.0
> >>   Block Name: cforms
> >>   Package: org.apache.cocoon.cforms
> >>   Namespace: http://apache.org/cocoon/forms/definition/1.0
> 
> sorry for missing the argumentation on keeping the 'forms' here, or is 
> this a typo?

AFAIU it this is by intention, no typo. It means the implementation of a new
form framework can happen in a parallel block, but the namespace always points
to *the* form framework. For a new framework accepted as replacement for Woody
later on the namespace will just change to 2.0.

+1 from me for the proposal (no IRC possible from here)

Joerg

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Geoff Howard]

[EMAIL PROTECTED] wrote:

Don't know if my vote counts, just in case: +1

Helma
 

Technically, the "vote" of a non-committer isn't binding, but your 
opinion (and anyone like you) is important and definitely "counts".  
Always feel free to pipe in.

Geoff

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Bertrand Delacretaz]

Le Vendredi, 5 mars 2004, à 17:16 Europe/Zurich, 
[EMAIL PROTECTED] a écrit :

Don't know if my vote counts, just in case: +1
Thanks!

Only votes from committers are "officially" counted but we always 
appreciate input from everybody.

-Bertrand

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Marc Portier]

Reinhard Pötz wrote:

Vadim Gritsenko wrote:

Reinhard Pötz wrote:

Tim Larson wrote:


...

+1 'cforms' instead of just 'forms'


I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?




Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0
sorry for missing the argumentation on keeping the 'forms' here, or is 
this a typo?

  NS Prefix: fd

and similar for binding and templating I presume? we might question if 
reordering the sub-domain and version-no is not more natural then:

xmlns:fd=http://apache.org/cocoon/cforms/1.0/definition
xmlns:fb=http://apache.org/cocoon/cforms/1.0/binding
wdot?

Title goes to documentation, samples, wiki, etc. Package name "cforms" 
and block name "cforms" will allow possibility of parallel development 
of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), 
when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one 
and only official forms framework. Namespace prefix "fd" stands for 
"forms definition".

Do we have a consensus now? Please chime in on IRC (somebody will have 
to count votes then), or here :-)

Vadim

+1 from me!

in prinipal +1 from me too, except for the small 
questions/clarifications above.

(sorry, didn't get to irc today)

maybe just adding arguments that might not be needed any more:

another argument for having [cforms] from my side was that you could 
never confuse it with the known english word 'form' that could mean an 
HTML form, a paper-form, a whatever formalism or whatnot... in 
discussions on these lists, and thus possibly introducing confusion that 
can be avoided

what I liked about 'woody' was that it meant what it meant in a not to 
be confused way (except for those damn aussies of course :-))... 
probably this very property was extended into a perception of having a 
'2nd brand within the cocoon brand'

I think cforms can nicely remove 'the brand within brand' feeling for 
those that find it necessary, stepping into 'forms' would have been 
killing the unique-naming-property that was the original reason for 
looking for a name for it in the first place

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: [SUMMARY] From Woody to Cocoon Forms 1.0

[H . vanderLinden]

Don't know if my vote counts, just in case: +1

Helma

> -Original Message-
> From: Steven Noels [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 05 March 2004 17:01
> To: [EMAIL PROTECTED]
> Subject: Re: [SUMMARY] From Woody to Cocoon Forms 1.0
> 
> 
> On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote:
> 
> > Do we have a consensus now? Please chime in on IRC 
> (somebody will have 
> > to count votes then), or here :-)
> 
> +1
> 
> 
> -- 
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source Java & XMLAn Orixo Member
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
> 

Experience with workflow at Hippo Webworks

[Johan Stuyts]

Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo. 
Below are our experiences.

As people with different levels of experience are interested in workflow I 
will start with a (very) brief introduction to workflow.

Workflow introduction
-
Very simply put workflow serves two purposes:
- to determine who can do what at which time with an object;
- to generate a list of pending tasks for users.
An example of the first is that an editor (who) can only publish (do what) 
a document (an object) after a writer has asked for a review (at which 
time).

The lists of documents to be reviewed is an example of a pending task list 
for an editor.

Each object type can have its own specific workflow.

The demo workflow
-
The demo we created has a workflow for a basic document type, a web page. 
I have attached a diagram of it.

A document gets created by a writer. The writer is not allowed to publish 
his document directly, he has to ask the editor for review.

The editor can easily review documents because we generate a list of 
documents waiting for review. The editor can click on the document and can 
either approve or disapprove. If the document gets approved it is 
published on the public server.

If the document gets disapproved the writer can not ask for a review 
without editing it first. Editing the document when it has been approved 
will bring the document back to the editing state too. After making his 
changes the user can ask for a review of the new version.

Implementation
--
For the document repository we use Slide. For the workflow engine we used 
OSWorkflow. We connected these two using Slide interceptors.

When a document is created the interceptor checks to see whether a 
workflow already exists. It does this by retrieving the workflow ID from a 
WebDAV property of the document. If it doesn't exist a new workflow is 
created in the workflow store.

When our frontend retrieves the tree of documents, the interceptor will 
retrieve the workflow for each document. Looking at the role of the user 
the interceptor will determine which actions are enabled. The enabled 
actions (including their display text and activation URLs) are set in a 
WebDAV property of the document.

For the generation of the pending task list we used the OSWorkflow query 
API to generate the documents which are in the waiting-for-review state. 
The approve and disapprove actions are passed to the frontend in the same 
way as the commands for a writer.

Not all actions are directly shown in the menu, because the user invokes 
them implicitly. The edit action for example is invoked by the interceptor 
each time the user saves the document.

Issues
--
We encountered issues with both slides and OSWorkflow during the 
implementation.

Before we used Slide, we used the Cocoon repository. The semantics of the 
repository interceptors and the Slide interceptors is not the same. With 
the repository interceptor we were able to add a property to the document 
in postStoreContent(...). In Slide we had to do this in 
preStoreContent(...).

Apart from that the Slide interceptors work very well, but (in the version 
of Slide we used) they get called a lot. A single store of a document 
invoked preStoreContent(...) and postStoreContent(...) multiple times.

OSWorkflow performed great too. The only disadvantage was the complexity 
of state machines that can be expressed. As you can see in the attached 
diagram nested states are used. OSWorkflow does not support these.

Although the attached workflow does not contain parallel states, we think 
it might be needed for some document types. A newsletter for example 
follows the same workflow as the attached one. But parallel to this is a 
mailing workflow for sending it to the newsletter subscribers.

In the mailing workflow the user can send a test email of the current 
version to himself. When he is satisfied he can send the final version to 
the newsletter subscribers. After this, he can neither send a test email 
nor send it to the subscribers.

But what to do if a mistake in the newsletter is found after sending it to 
the subscribers? The subscribers won't be happy to receive another copy, 
so the mailing actions should stay blocked. But not correcting the 
newsletter on the website looks sloppy. Therefore the 
editing/reviewing/publishing workflow has to remain active.

Workflow requirements
-
Building an effective and solid workflow solution requires two 
preconditions. Both are outside the scope of the workflow framework:
- understandable role assignment (from a user's perspective) and simple 
role retrieval;
- typed document repository. This is necessary to enable different 
document types having different workflows attached to them.

When these two preconditions are met, the workflow framework must meet the 
following

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Steven Noels]

On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote:

Do we have a consensus now? Please chime in on IRC (somebody will have 
to count votes then), or here :-)
+1


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

RE: From Woody to CocoonForms

[Ralph Goers]

I am not in favor of having FormValidatorAction and SimpleFormsTransformer
deprecated.  They are lightweight and do the job they were intended to do.

 -Original Message-
From:   Reinhard Pötz [mailto:[EMAIL PROTECTED] 
Sent:   Friday, March 05, 2004 4:51 AM
To: [EMAIL PROTECTED]
Subject:Re: From Woody to CocoonForms

[EMAIL PROTECTED] wrote:
All other form implementation will be deprecated soon. IMO we should 
make this clear by moving those blocks into a "deprecated-blocks" 
directory.

WDOT?

-- 
Reinhard

Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Reinhard Pötz]

Vadim Gritsenko wrote:

Reinhard Pötz wrote:

Tim Larson wrote:


...

+1 'cforms' instead of just 'forms'
I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?


Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a 
little chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0
  NS Prefix: fd
Title goes to documentation, samples, wiki, etc. Package name "cforms" 
and block name "cforms" will allow possibility of parallel development 
of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), 
when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one 
and only official forms framework. Namespace prefix "fd" stands for 
"forms definition".

Do we have a consensus now? Please chime in on IRC (somebody will have 
to count votes then), or here :-)

Vadim

+1 from me!

--
Reinhard

Re: ASF 2.0 license upgrade - how?

[Bertrand Delacretaz]

Le Vendredi, 5 mars 2004, à 16:04 Europe/Zurich, Reinhard Pötz a écrit :

The new licence reduced or code (within the src directory) from
51.235.015 bytes to 46.831.266 bytes. Nice to see this! :-)
Cool!

FYI, I've now committed the results of running ReplaceLicense on the 
whole tree, see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467

I won't be able to work on this in the next few days. If someone works 
on it, please tag the various steps so that we can trace things if 
needed.

I think Antonio was about to commit the results of running 
insert_license.pl, but he just disappeared from IRC, he might be having 
connection problems.

-Bertrand

DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license

[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=27467

Upgrade all source files to ASF 2.0 license





--- Additional Comments From [EMAIL PROTECTED]  2004-03-05 15:31 ---
I have added the egrep diff-checking script as tools/relicense/check-diffs.sh to
prevent any problems with copying/pasting from here.

[SUMMARY] From Woody to Cocoon Forms 1.0

[Vadim Gritsenko]

Reinhard Pötz wrote:

Tim Larson wrote:
...

+1 'cforms' instead of just 'forms' 

I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is 
obvious because it's within the Cocoon CVS.
WDOT?


Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little 
chat on IRC and agreed on the following:

  Block Title: Cocoon Forms, or Cocoon Forms 1.0
  Block Name: cforms
  Package: org.apache.cocoon.cforms
  Namespace: http://apache.org/cocoon/forms/definition/1.0
  NS Prefix: fd
Title goes to documentation, samples, wiki, etc. Package name "cforms" 
and block name "cforms" will allow possibility of parallel development 
of the next generation "Cocoon Forms 2.0" (block name dforms ;-)), 
when/if it happens. Namespace suggests that Cocoon Forms 1.0 is one and 
only official forms framework. Namespace prefix "fd" stands for "forms 
definition".

Do we have a consensus now? Please chime in on IRC (somebody will have 
to count votes then), or here :-)

Vadim

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

[Joerg Heinicke]

Vadim Gritsenko  reverycodes.com> writes:

> >>
> >>  
> >>
> >>
> >>  
> >>  
> >>
> >>
> >>  
> >>
> 
> I also tend to prefer this approach - same reasoning with ambiguity of 
> unique attribute.

Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is
outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though
it is executed also at on-bind event.

Maybe a third alternative helps for that:


  

  
  



  


And a fourth one is to specify values used for uniqueness independent on binding:


  



  
  




  


I used wb:element because I had no name in mind. It also must be clear if you
refer to path (bean or XML) or to id (form model widget). From the XML this is
very similar to Antonio's original proposal and current implementation, but
there is the important difference that there does *not* happen any binding on
wb:unique-row and children. Therefore it's probably clearer than the other
proposals but more verbose.

WDYT?

Joerg

XSLT test suite?

[Bertrand Delacretaz]

We've had several mysterious issues with the various XSLT processors, 
it would be good to have an XSLT test suite to validate our processors 
and check for regressions.

Googling led me to XSLTMark [1] but the download link is broken.

Before investigating too much, has anyone used it, or does anyone know 
of another good (extensible) test suite that we could use?

-Bertrand

[1] http://www.datapower.com/xmldev/xsltmark.html

Re: [cforms] Woody template transformer eating namespaced element tags?

[Steve Krulewitz]

wild guess: perhaps 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24793 ?
No it doesn't look like it.  This bug is about missing namespaces and 
attributes, not element names.  Also, my problem seems to be caused by 
the woody template transformer -- if I remove it, everything works fine.

cheers,
-steve

Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/store JCSStore.java

[Reinhard Pötz]

[EMAIL PROTECTED] wrote:

unico   2004/03/05 07:05:02

 Modified:src/blocks/scratchpad/java/org/apache/cocoon/components/store
   JCSStore.java
 Log:
 clean up logging and add some TODOs
 
 Revision  ChangesPath
 1.3   +19 -25cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/store/JCSStore.java
 
 Index: JCSStore.java
 ===
 RCS file: /home/cvs/cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/store/JCSStore.java,v
 retrieving revision 1.2
 retrieving revision 1.3
 diff -u -r1.2 -r1.3
 --- JCSStore.java	5 Mar 2004 10:07:26 -	1.2
 +++ JCSStore.java	5 Mar 2004 15:05:02 -	1.3
 @@ -93,7 +93,10 @@
   *  group-name: the group to be used as defined in the config file
   *
   *  
 - *
 + * 
 + * TODO: instead of loading properties from an external file we may want to
 + * specify them using parameters.

 

This would be fine (I don't like it if we have so many configuration 
files around ... cocoon.xconf, logkit.xconf, ojb.properties is enough)

--
Reinhard

Re: ASF 2.0 license upgrade - how?

[Reinhard Pötz]

The new licence reduced or code (within the src directory) from
51.235.015 bytes to 46.831.266 bytes. Nice to see this! :-)
--
Reinhard

Re: From Woody to CocoonForms

[Reinhard Pötz]

[EMAIL PROTECTED] wrote:

I could be wrong (that happens often enough), but what if we 
eventually
replace Woody/Cocoon Forms with something better?  If it is very
different then IMHO just a namespace version change 1.0->2.0, etc. may
not make a lot of sense.  A new name may be in order at that point.
If we start the pattern with CForms then we have a non-fantasy name,
while still leaving room for future names for new forms frameworks
(Super Forms -> SForms, etc.)
   

+1 from me. :-)

I thought of the present variations, which are all nominated for
deprecation, but yes, looking to the future you keep the possibility of
distinction.
Yes, ideally there will be only one type of forms and nothing more, but I
suppose that was the idea too when XMLForms emerged.
Why not meet halfway: wforms as a contribution to the old name (woody) and
allow for a possible future sforms.
I think Cocoon is powerful enough "as a brand" to allow for different names.
After all, reading into Cocoon dropped many more projects/names etc. in my
lap: avalon, excalibur, xindice, poi, batik, etc.
Ok, woody "emerged" from Cocoon, and I don't want to repeat the "yes/no
renaming discussion", but I don't think you have to be that strict.
 

That's the point: Cocoon Forms is part of Cocoon and supported by the 
Cocoon community. If somebody wants to come up with another 
implementation we won't stop him but it will *not* be the official forms 
framework. And if we think one day that the new framework is superior to 
the old one we can decide that we want to have a new Cocoon Forms 
version (indicated by the version number --> also note: Cocoon 1.0 has 
from the technological base nothin in common with Cocoon 2.0!)

Going this way we can be sure that there is only one 'official' forms 
framework.

--
Reinhard

Re: Turning off default MRU store

[Unico Hommes]

Geoff Howard wrote:

Unico Hommes wrote:

Sylvain Wallez wrote:

Unico Hommes wrote:

Unico Hommes wrote:



Corin Moss wrote:

Hi Guys,

I might be getting ahead of myself a bit here, but I'm going to 
try and turn off the default MRU store, in favour of the JCS 
based persistent store.  I'd like to try some tests on 
performance without the default MRU - has anyone else tried 
anything similar? I've simply set the core store's role to point 
to the JCS store implementation.

I guess I already got ahead of you when I renamed 
JCSPersistentStore JCSStore just now :-) (And merged it with the 
AbstractJCSStore BTW). It seems to me that JCS is both and it 
could replace all three stores: DefaultStore, TransientStore and 
PersistentStore.

I have to add that this is not the whole story. We do actually need 
to distinguish between persistent and transient storage. Some 
components explicitly want to persist some data instead of just 
cache it for speed. But as far as caching is concerned I think it 
we can leave it completely up to JCS.




Some components are explicitely using the transient-store to keep 
data that shouldn't (or cannot) be serialized. But AFAIK, no 
component directly uses the persistent-store except the store itself.

To my knowlegde there is one in eventcache block that uses the 
PersistentStore to persist some info it needs to recover upon next 
startup.

It does not look to me as though JCS would fit the PersistentStore 
role very well. I was thinking that perhaps. We could have JCSStore 
as a replacement for TransientStore and Store roles and use 
FilesystemStore for the PersistentStore role.


Wait a minute.  The original issue that brought JCS to the front as 
that the persistent store was broken and had license problems.  Are 
you saying that JCS isn't a good candidate for persisting the cached 
info to disk, or that the fact that it by default has an MRU memory 
front-end makes it not map directly to persistent-store role cleanly?

IIUC, JCS will always use a memory store in front yes. And it suggests 
on the JCS website that the persistence process is not very reliable:

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

"When the disk cache is properly shutdown, the memory index is written 
to disk and the value file is defragmented. When the cache starts up, 
the disk cache can be configured to read or delete the index file. This 
provides an unreliable persistence mechanism."

The use of persistent store in eventcache shouldn't be a problem with 
JCS as long as at shutdown, it persists everything it has in its MRU 
if it hasn't already.  If there is some problem it would be much 
better to just go back to the old serializing persistence for the 
event cache data because the only benefit to putting it in the store 
is that you more or less guaranteed that the events and cached 
responses would be kept together.


Yes, giving up that feature would be too bad.

Unico

RE: From Woody to CocoonForms

[H . vanderLinden]

> I could be wrong (that happens often enough), but what if we 
> eventually
> replace Woody/Cocoon Forms with something better?  If it is very
> different then IMHO just a namespace version change 1.0->2.0, etc. may
> not make a lot of sense.  A new name may be in order at that point.
> If we start the pattern with CForms then we have a non-fantasy name,
> while still leaving room for future names for new forms frameworks
> (Super Forms -> SForms, etc.)

+1 from me. :-)

I thought of the present variations, which are all nominated for
deprecation, but yes, looking to the future you keep the possibility of
distinction.

Yes, ideally there will be only one type of forms and nothing more, but I
suppose that was the idea too when XMLForms emerged.

Why not meet halfway: wforms as a contribution to the old name (woody) and
allow for a possible future sforms.

I think Cocoon is powerful enough "as a brand" to allow for different names.
After all, reading into Cocoon dropped many more projects/names etc. in my
lap: avalon, excalibur, xindice, poi, batik, etc.
Ok, woody "emerged" from Cocoon, and I don't want to repeat the "yes/no
renaming discussion", but I don't think you have to be that strict.

Bye, Helma

Re: From Woody to CocoonForms

[Reinhard Pötz]

Tim Larson wrote:

On Fri, Mar 05, 2004 at 03:15:56PM +0100, Reinhard P?tz wrote:
 

Tim Larson wrote:
   

On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
 

Sylvain Wallez wrote:
   

[EMAIL PROTECTED] wrote:
 

Hi,
   

In the next few days I want (no promise ;-) to start with renaming 
Woody to CocoonForms. First I want to move the _core_ which means 
that I want to make one simple example run.

namespaces:
http://apache.org/cocoon/woody/definition/1.0
-->
http://apache.org/cocoon/forms/definition/1.0
 

Are there other 'forms' types? Maybe you could use "cforms" since that 
is the most often used abbreviation and to set it apart from other 
form types.

   

+1 (although I'm one of those that will miss "woody")

 

another +1 to 'cforms' over 'forms'
(and joining in on the 'will miss the original')
   

+1 'cforms' instead of just 'forms'

 

I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious 
because it's within the Cocoon CVS.
WDOT?
   

I could be wrong (that happens often enough), but what if we eventually
replace Woody/Cocoon Forms with something better?  If it is very
different then IMHO just a namespace version change 1.0->2.0, etc. may
not make a lot of sense.  A new name may be in order at that point.
If we start the pattern with CForms then we have a non-fantasy name,
while still leaving room for future names for new forms frameworks
(Super Forms -> SForms, etc.)
I'll be quiet now :)
 

That's a point, of course. OTOH we decided that this community will 
support only one forms framework in the future. We will deprecate 
everything else very soon.
Suppose that somebody starts to implement another forms framework and we 
vote that this will be the official forms framwork in the future. This 
would mean that we deprecate the former forms framework in favour of the 
new one. The new one will have the name Cocoon Forms 2.0 and will be in 
the forms block.

I'm +1 for "forms" because this makes it very clear that there is only 
one and not more.

--
Reinhard

Re: Turning off default MRU store

[Geoff Howard]

Unico Hommes wrote:

Sylvain Wallez wrote:

Unico Hommes wrote:

Unico Hommes wrote:



Corin Moss wrote:

Hi Guys,

I might be getting ahead of myself a bit here, but I'm going to 
try and turn off the default MRU store, in favour of the JCS based 
persistent store.  I'd like to try some tests on performance 
without the default MRU - has anyone else tried anything similar? 
I've simply set the core store's role to point to the JCS store 
implementation.

I guess I already got ahead of you when I renamed 
JCSPersistentStore JCSStore just now :-) (And merged it with the 
AbstractJCSStore BTW). It seems to me that JCS is both and it could 
replace all three stores: DefaultStore, TransientStore and 
PersistentStore.

I have to add that this is not the whole story. We do actually need 
to distinguish between persistent and transient storage. Some 
components explicitly want to persist some data instead of just 
cache it for speed. But as far as caching is concerned I think it we 
can leave it completely up to JCS.




Some components are explicitely using the transient-store to keep 
data that shouldn't (or cannot) be serialized. But AFAIK, no 
component directly uses the persistent-store except the store itself.

To my knowlegde there is one in eventcache block that uses the 
PersistentStore to persist some info it needs to recover upon next 
startup.

It does not look to me as though JCS would fit the PersistentStore 
role very well. I was thinking that perhaps. We could have JCSStore as 
a replacement for TransientStore and Store roles and use 
FilesystemStore for the PersistentStore role.


Wait a minute.  The original issue that brought JCS to the front as that 
the persistent store was broken and had license problems.  Are you 
saying that JCS isn't a good candidate for persisting the cached info to 
disk, or that the fact that it by default has an MRU memory front-end 
makes it not map directly to persistent-store role cleanly?

The use of persistent store in eventcache shouldn't be a problem with 
JCS as long as at shutdown, it persists everything it has in its MRU if 
it hasn't already.  If there is some problem it would be much better to 
just go back to the old serializing persistence for the event cache data 
because the only benefit to putting it in the store is that you more or 
less guaranteed that the events and cached responses would be kept together.

Geoff

So if the JCSStore includes a MRU-like memory front-end, it can 
simply replace the  component in cocoon.xconf.

My thoughts exactly

Re: From Woody to CocoonForms

[Tim Larson]

On Fri, Mar 05, 2004 at 03:15:56PM +0100, Reinhard P?tz wrote:
> Tim Larson wrote:
> >On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
> >>Sylvain Wallez wrote:
> >>>[EMAIL PROTECTED] wrote:
> Hi,
> >In the next few days I want (no promise ;-) to start with renaming 
> >Woody to CocoonForms. First I want to move the _core_ which means 
> >that I want to make one simple example run.
> >
> >namespaces:
> >http://apache.org/cocoon/woody/definition/1.0
> >-->
> >http://apache.org/cocoon/forms/definition/1.0
> >
> Are there other 'forms' types? Maybe you could use "cforms" since that 
> is the most often used abbreviation and to set it apart from other 
> form types.
> 
> >>>+1 (although I'm one of those that will miss "woody")
> >>>
> >>another +1 to 'cforms' over 'forms'
> >>(and joining in on the 'will miss the original')
> >
> >+1 'cforms' instead of just 'forms'
> >
> I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious 
> because it's within the Cocoon CVS.
> WDOT?

I could be wrong (that happens often enough), but what if we eventually
replace Woody/Cocoon Forms with something better?  If it is very
different then IMHO just a namespace version change 1.0->2.0, etc. may
not make a lot of sense.  A new name may be in order at that point.
If we start the pattern with CForms then we have a non-fantasy name,
while still leaving room for future names for new forms frameworks
(Super Forms -> SForms, etc.)

I'll be quiet now :)

--Tim Larson

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

[Vadim Gritsenko]

Tim Larson wrote:

On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote:
 


 
   
   
 
 
   
   
 

   

I also tend to prefer this approach - same reasoning with ambiguity of 
unique attribute.



 
   
   
   
   
 

What do the other people think?
   

I do not like this option, because it implies that the two wb:value's
are individually unique.  The first example above (with wb:unique-row)
gives the right implication, that the values when combined identify a
unique row.  I have mixed feelings about using wb:unique-row, wb:key,
or wb:unique-key, but I might be leaning toward wb:key.
 

I'm ok with ... Oh, and I can suggest  - this will 
not have RDBMS background :-)

Vadim

Re: From Woody to CocoonForms

[Reinhard Pötz]

[EMAIL PROTECTED] wrote:

Are there other 'forms' types? Maybe you could use "cforms" 
 

since that is the most often used abbreviation and to set it 
apart from other form types.
   



 

+1 (although I'm one of those that will miss "woody")
   

Me too, I didn't follow the thread on why this renaming should take place,
but for me woody is nice enough, no renaming necessary.
Bye, Helma
 

Reasons can be found in the archives - main reason IMH is, that we 
should only have one "brand" and this is Cocoon.

--
Reinhard

Re: From Woody to CocoonForms

[Reinhard Pötz]

Tim Larson wrote:

On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
 

Sylvain Wallez wrote:
   

[EMAIL PROTECTED] wrote:
 

Hi,
   

In the next few days I want (no promise ;-) to start with renaming 
Woody to CocoonForms. First I want to move the _core_ which means 
that I want to make one simple example run.

namespaces:
http://apache.org/cocoon/woody/definition/1.0
-->
http://apache.org/cocoon/forms/definition/1.0
 

Are there other 'forms' types? Maybe you could use "cforms" since that 
is the most often used abbreviation and to set it apart from other 
form types.
   

+1 (although I'm one of those that will miss "woody")
 

another +1 to 'cforms' over 'forms'
(and joining in on the 'will miss the original')
   

+1 'cforms' instead of just 'forms'
 

I'm +1 for "forms" only - as Vadim pointed out, it's "Cocoon" is obvious 
because it's within the Cocoon CVS.
WDOT?

--
Reinhard

Re: Turning off default MRU store

[Unico Hommes]

Sylvain Wallez wrote:

Unico Hommes wrote:

Unico Hommes wrote:



Corin Moss wrote:

Hi Guys,

I might be getting ahead of myself a bit here, but I'm going to try 
and turn off the default MRU store, in favour of the JCS based 
persistent store.  I'd like to try some tests on performance 
without the default MRU - has anyone else tried anything similar? 
I've simply set the core store's role to point to the JCS store 
implementation.

I guess I already got ahead of you when I renamed JCSPersistentStore 
JCSStore just now :-) (And merged it with the AbstractJCSStore BTW). 
It seems to me that JCS is both and it could replace all three 
stores: DefaultStore, TransientStore and PersistentStore.

I have to add that this is not the whole story. We do actually need 
to distinguish between persistent and transient storage. Some 
components explicitly want to persist some data instead of just cache 
it for speed. But as far as caching is concerned I think it we can 
leave it completely up to JCS.


Some components are explicitely using the transient-store to keep data 
that shouldn't (or cannot) be serialized. But AFAIK, no component 
directly uses the persistent-store except the store itself.

To my knowlegde there is one in eventcache block that uses the 
PersistentStore to persist some info it needs to recover upon next startup.

It does not look to me as though JCS would fit the PersistentStore role 
very well. I was thinking that perhaps. We could have JCSStore as a 
replacement for TransientStore and Store roles and use FilesystemStore 
for the PersistentStore role.

So if the JCSStore includes a MRU-like memory front-end, it can simply 
replace the  component in cocoon.xconf.

My thoughts exactly

Unico