ASF 2.0 license upgrade - how?
Hi FirstFridayists, How do we go with the license change? The src/java/org/apache/committers/ReplaceLicense.java class from committers module looks good, but maybe we should try it on a smaller part of the tree before doing the whole thing. I could start right away and: a) tag the 2.1 tree b) run ReplaceLicense on the scratchpad only c) if it compiles, commit and let others check it before doing the whole tree How does this sound? -Bertrand
RE: ASF 2.0 license upgrade - how?
Bertrand Delacretaz wrote: All other files were updated by hand as they didn't have a license before - but perhaps there is an easier way. Doesn't ReplaceLicense add it if absent? haven't looked yet. I don't think so. In that case it had to look at the content type (xml, html, properties file, text file, image etc) and do the appropriate action. Doing it by hand was imho safer (there were only approx. 50 non java files). Carsten, you're not on IRC? One of your colleagues is there so it might be possible ;-) Who? :) I've to go to a meeting this morning, but I wanted to join at 12:00. Carsten
DO NOT REPLY [Bug 27467] New: - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 Summary: Upgrade all source files to ASF 2.0 license Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] See instructions in http://www.apache.org/dev/apply-license.html Needs changing the license header in every java source file, and adding it to all non-binary files IIUC. I will note here the CVS tags set on the tree in the different phases of the relicensing, in case something weird happens.
Re: ASF 2.0 license upgrade - how?
Chaps, The Geronimo project recently performed a migration of all of their code using a bunch of perl scripts. May be worth looking at if we have trouble with the below. The scripts were run by Gianny Damour, and are available to committers in his home directory, ~gdamour/LicenseMigration/. Paul On 5 Mar 2004, at 08:35, Carsten Ziegeler wrote: Bertrand Delacretaz wrote: All other files were updated by hand as they didn't have a license before - but perhaps there is an easier way. Doesn't ReplaceLicense add it if absent? haven't looked yet. I don't think so. In that case it had to look at the content type (xml, html, properties file, text file, image etc) and do the appropriate action. Doing it by hand was imho safer (there were only approx. 50 non java files). Carsten, you're not on IRC? One of your colleagues is there so it might be possible ;-) Who? :) I've to go to a meeting this morning, but I wanted to join at 12:00. Carsten -- Paul Russell [EMAIL PROTECTED]
RE: ASF 2.0 license upgrade - how?
Sounds good :) I used that tool for the java sources of the Pluto project and it did work very well. All other files were updated by hand as they didn't have a license before - but perhaps there is an easier way. Carsten -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 9:19 AM To: [EMAIL PROTECTED] Subject: ASF 2.0 license upgrade - how? Hi FirstFridayists, How do we go with the license change? The src/java/org/apache/committers/ReplaceLicense.java class from committers module looks good, but maybe we should try it on a smaller part of the tree before doing the whole thing. I could start right away and: a) tag the 2.1 tree b) run ReplaceLicense on the scratchpad only c) if it compiles, commit and let others check it before doing the whole tree How does this sound? -Bertrand
[CForms] [RT] Simplified XML-binding
Hi, I don't know, if you had the same experience, but it always feels nasty to me when I do simple XML bindings, where xml element names and field ids are always called the same. Wouldn't it be good to make some attributes optional in the binding definition? Here's a partial example from the file form2_bind_xml.xml: wb:repeater id=contacts parent-path=contacts row-path=contact unique-row-id=id unique-path=@id wb:on-bind wb:value id=firstname path=firstname/ wb:value id=lastname path=lastname/ wb:value id=phone path=phone/@nr/ wb:value id=email path=email/ /wb:on-bind /wb:repeater That's what I'd like to write: wb:repeater id=contacts row-path=contact unique-row-id=id unique-path=@id wb:on-bind wb:value id=firstname/ wb:value id=lastname/ wb:value id=phone path=phone/@nr/ wb:value id=email/ /wb:on-bind /wb:repeater So what I mean is, that if the @path is missing on wb:value it defaults to the same as @id and if @parent-path is missing on wb:repeater it defaults to @id too. Perhaps there are some more simplifications possible. What do others think? Bye, Andreas
Re: ASF 2.0 license upgrade - how?
Le Vendredi, 5 mars 2004, à 09:26 Europe/Zurich, Carsten Ziegeler a écrit : Sounds good :) Ok, I'll go ahead with the scratchpad then. I used that tool for the java sources of the Pluto project and it did work very well. cool All other files were updated by hand as they didn't have a license before - but perhaps there is an easier way. Doesn't ReplaceLicense add it if absent? haven't looked yet. Carsten, you're not on IRC? One of your colleagues is there so it might be possible ;-) -Bertrand
Re: [cforms] Woody template transformer eating namespaced element tags?
I got the same problem even in 2.1.5-dev Roy Huang - Original Message - From: Steve Krulewitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 05, 2004 7:14 AM Subject: Re: [cforms] Woody template transformer eating namespaced element tags? I did a little more poking around, and it turns out that even though the woody template transformer mangles the xml document, the problem does not appear unless you run the document through the identity xslt transform. Simple example: test.xml html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html test.xsl ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template /xsl:stylesheet pipeline map:match pattern=test map:generate src=test.xml/ map:transform type=woody/ map:transform src=test.xsl/ map:serialize/ /map:match Will produce xmlns=http://www.w3.org/1999/xhtml; Hello World / / But if you remove the woody transform or the xslt, you get ~~ html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html
[RESULTS jdk userlist poll ]
It's been about a day since the last poll reply came through, i guess it's either too far down in the newsreader overview for people to still notice it or maybe just everyone who wanted to vote actually has voted. The poll : COCOON : your version here JDK : your version here CONTAINER : your version here (optional) PRO/CON 1.4 requirement for 2.2 : opinion here The results : - 33 people participated. - Some indicated 2 or more environments (dev/production etc), some only one. - Some indicated detailed version numbers, others just main releases. - Environments (not users) are counted in below results so the totals won't always add up. COCOON - 1.x : none (but recent posts indicate still live 1.8 installs) 2.0.x :6 -2.0.3: 3 -2.0.4: 2 -2.0.5dev : 1 2.1.x :33 -2.1.0 :1 -2.1.2 :4 -2.1.3 :7 -2.1.4 :11 -2.1.4dev:2 -2.1.5dev:6 JDK - 1.3.1 :5 1.4.1 :11 1.4.2 :21 CONTAINER - Jetty 4.21 OC4J 9.0.4/10g1 SAP J2EE1 Weblogic4 -72 -82 Websphere2 -41 -51 Tomcat 4.1.x23 Tomcat 5.0.x8 PROC/CON 1.4 Req - ABSTAIN8 CON3 PRO22 The results spreadsheet is available for those who want to do more detailed analysis, please mail me offlist. Regards Jorg
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 10:01 --- cvs tag ASF_20_BEFORE set before doing any changes.
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 10:35 --- I'm using this to make (more or less) sure that only license-related stuff has changed: cvs -z3 diff -r ASF_20_BEFORE . /tmp/diff.txt And then (don't you like brute-force regexps ;-) egrep -v '\*.*\*|Copyright|Licensed|ou may|LICENSE-2.0|Unless|distributed|RCS file|Apache Cocoon|THIS SOFTWARE|INCLUDING|FITNESS|APACHE SOFTWARE|INDIRECT|DING,|OF USE|ANY THEORY|This software|on behalf|information on the|Software Foundation|THEORY OF LIAB|WARRANTIES|the License|Redistributions|this list|or other mat|end-user documentation included|following ack|this ack|used to endorse|prior written|derived from|without prior|Apache Software License|Redistribution and use|are permitted|include *the following|acknowledge?ment may|[EMAIL PROTECTED]|Apache Software Foundation|and wherever|retrieving revision|@version|\*|^\ ?|^ ?|=|---|^Index:|^diff |^[0-9]+\,[0-9]+[a-z].*|[0-9]+[a-z][0-9]+' /tmp/diff.txt
Re: [cforms] Woody template transformer eating namespaced element tags?
wild guess: perhaps http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24793 ? roy huang wrote: I got the same problem even in 2.1.5-dev Roy Huang - Original Message - From: Steve Krulewitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 05, 2004 7:14 AM Subject: Re: [cforms] Woody template transformer eating namespaced element tags? I did a little more poking around, and it turns out that even though the woody template transformer mangles the xml document, the problem does not appear unless you run the document through the identity xslt transform. Simple example: test.xml html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html test.xsl ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template /xsl:stylesheet pipeline map:match pattern=test map:generate src=test.xml/ map:transform type=woody/ map:transform src=test.xsl/ map:serialize/ /map:match Will produce xmlns=http://www.w3.org/1999/xhtml; Hello World / / But if you remove the woody transform or the xslt, you get ~~ html xmlns=http://www.w3.org/1999/xhtml; body Hello World /body /html -- Jan Uyttenhove [EMAIL PROTECTED] Xume - http://www.xume.com smime.p7s Description: S/MIME Cryptographic Signature
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 10:41 --- Sorry should have been cvs -z3 diff -b -r ASF_20_BEFORE . /tmp/diff.txt to ignore whitespace changes
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 10:51 --- Scratchpad builds ok, tagged: src/blocks/scratchpad cvs tag ASF_20_SCRATCHPAD_AUTO .
Re: ASF 2.0 license upgrade - how?
Le Vendredi, 5 mars 2004, à 09:48 Europe/Zurich, Paul Russell a écrit : ...The Geronimo project recently performed a migration of all of their code using a bunch of perl scripts. May be worth looking at if we have trouble with the below Thanks for the info - committers, note that there is an add license script there that can be useful even if we use ReplaceLicense.java for the rest. The scratchpad block is done and looks good, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467 for more info. -Bertrand
Re: Instrumentation, anyone?
Thor Heinrichs-Wolpert wrote: XDoclet is a good generator, but the license is wrong for Apache. Using straight Introspection can and will expose things that you do not wish to allow users to alter on the fly. Unfortunately I'm completely snowed under until March 29th. After that date I will get back to working on JMX for cocoon. I suggested using the MX4J libraries as they are under an Apache license already, but haven't heard any thoughts here. Well, looks like your much more JMX-savy than the rest of us, so I'll happily leave you the driver seat. :-) I'm fine with MX4J, at least as a starting point. We could use XML Descriptors that could be used to create dynamic MBeans. As for generation, we could generate MBeans directly, or XML descriptors from comments in the code (a'la XDoclet), the downside to this requires having access to (and modifying) the source code. Yes, that might be bad for the core avalon part. Let me know which way you think will fit in the best way for cocoon'ers and I can start on that in April. Cool. Will look forward to it, while documenting myself on the whole JMX stuff. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
New licenses year.... (was: Re: ASF 2.0 license upgrade - how?)
hi: As part of the new licenses work, we also need to add licenses to files that currently does not have any. The question is: What year range use? 1999-2004 or just 2004? Rememeber the CVS history was lost. Best Regards, Antonio Gallardo
Re: ASF 2.0 license upgrade - how?
Le Vendredi, 5 mars 2004, à 09:18 Europe/Zurich, Bertrand Delacretaz a écrit : ...I could start right away and: a) tag the 2.1 tree b) run ReplaceLicense on the scratchpad only c) if it compiles, commit and let others check it before doing the whole tree FYI, this is done, see Next, I've now run ReplaceLicense in the src directory and the diffs look ok. But starting with ./cocoon.sh servlet I get a lot of there was no xindice.db.home property set and the JVM exits, weird. I'll do a clean build and check before committing - but if someone wants to go ahead fine, I'm off for lunch now. -Bertrand
Re: ASF 2.0 license upgrade - how?
FYI, this is done, see I meant see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467; -Bertrand
Re: New licenses year....
Antonio Gallardo wrote: hi: As part of the new licenses work, we also need to add licenses to files that currently does not have any. The question is: What year range use? 1999-2004 or just 2004? Rememeber the CVS history was lost. Best Regards, Antonio Gallardo If we use 1999 we are on the save side (IMO) -- Reinhard
RE: From Woody to CocoonForms
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. Bye, Helma
RE: From Woody to CocoonForms
Sounds good to me. +1 From your description, I guess you want to add a new block for Cocoon Forms in parallel to the Woody one, right? Carsten -Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 1:18 PM To: [EMAIL PROTECTED] Subject: From Woody to CocoonForms 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. Of course, this renaming has impact on many names and in order to avoid doing the same thing twice I want to here other opinions on this: namespaces: http://apache.org/cocoon/woody/definition/1.0 -- http://apache.org/cocoon/forms/definition/1.0 packages: org.apache.cocoon.woody.transformation -- org.apache.cocoon.forms.transformation classnames: AbstractWoodyAction -- AbstractCocoonFormsAction xconf: woody-datatype logger=woody -- forms-datatype logger=forms What do you think? I don't do the whole transformation at once because I know that I don't have enough time. So I hope that some others jump in hint/ ;-) But this has also a technical impact: the libs (oro, reporter-expressions) have to move for some time to lib/optional (IIUC). -- Reinhard
JCSStore causes stack overflow?
While applying the new license I found out that a complete build with all blocks does not start, I get a stack overflow. Stack trace shows repeated calls to JCSStore.parameterize. After commenting this element in cocoon.xconf, startup is ok: persistent-store class=org.apache.cocoon.components.store.JCSStore logger=core.store.persistent I didn't test this before running ReplaceLicense but I don't think it is related. -Bertrand
Re: From Woody to CocoonForms
[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. Bye, Helma 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: From Woody to CocoonForms
Carsten Ziegeler wrote: Sounds good to me. +1 From your description, I guess you want to add a new block for Cocoon Forms in parallel to the Woody one, right? Yep as it is much work and I'm not sure on all parts if they are _official_ or not. -- Reinhard
RE: JCSStore causes stack overflow?
---BeginMessage--- Hmm, I won't say that it's impossible ;) But I've been hitting the store pretty heavily today (000's of objects cached) and I've not yet had such a problem, AFAIK it should only be calling the parameterize once - when it first initialises the store, although that's defined by other interfaces, so I'm not sure. Can you post your config block for the JCS Store, and also the CCF file you're using to configure it? Thanks, Corin -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Sat 6/03/2004 1:51 a.m. To: [EMAIL PROTECTED] Cc: Subject: JCSStore causes stack overflow? While applying the new license I found out that a complete build with all blocks does not start, I get a stack overflow. Stack trace shows repeated calls to JCSStore.parameterize. After commenting this element in cocoon.xconf, startup is ok: persistent-store class=org.apache.cocoon.components.store.JCSStore logger=core.store.persistent I didn't test this before running ReplaceLicense but I don't think it is related. -Bertrand winmail.dat---End Message--- 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: JCSStore causes stack overflow?
Bertrand Delacretaz wrote: While applying the new license I found out that a complete build with all blocks does not start, I get a stack overflow. Stack trace shows repeated calls to JCSStore.parameterize. After commenting this element in cocoon.xconf, startup is ok: persistent-store class=org.apache.cocoon.components.store.JCSStore logger=core.store.persistent I didn't test this before running ReplaceLicense but I don't think it is related. No not related. I've had this before and it is related to a circular dependency: JCStore - SourceResolver - RepositorySource/CachingSource - Cache - JCSStore Try commenting out RepositorySource. I will look into fixing it in a few. Unico
Re: From Woody to CocoonForms
Le Vendredi, 5 mars 2004, à 13:18 Europe/Zurich, Reinhard Pötz a écrit : ... namespaces: packages: ... classnames: ... xconf: ... What do you think? Quite frankly, I think changing implementation-specific names (packages, classes) is not worth the hassle. I'd change just the namespaces maybe, assuming they *might* be used for another implementation besides woody in the future, the block name and mostly the documentation. I don't mind keeping woody as the technical name in some places, IMHO the name change disruption is not worth it. ...I don't do the whole transformation at once because I know that I don't have enough time. So I hope that some others jump in hint/ ;-)... And that's a big problem, the risk of having a half-finished renaming is big if we aim too high. -Bertrand
Re: JCSStore causes stack overflow?
Le Vendredi, 5 mars 2004, à 14:01 Europe/Zurich, Unico Hommes a écrit : No not related. I've had this before and it is related to a circular dependency: JCStore - SourceResolver - RepositorySource/CachingSource - Cache - JCSStore Try commenting out RepositorySource. I will look into fixing it in a few. No problem, I've been able to start. I was just worried at first that ReplaceLicense had messed up something (and that my egrep thing had not seen the problem ;-) -Bertrand
Re: From Woody to CocoonForms
On Fri, 2004-03-05 at 13:54, Reinhard Pötz wrote: Carsten Ziegeler wrote: Sounds good to me. +1 From your description, I guess you want to add a new block for Cocoon Forms in parallel to the Woody one, right? Yep as it is much work and I'm not sure on all parts if they are _official_ or not. Hmm, I thought this was just about renaming woody and nothing more? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: From Woody to CocoonForms
Bertrand Delacretaz wrote: Le Vendredi, 5 mars 2004, à 13:18 Europe/Zurich, Reinhard Pötz a écrit : ... namespaces: packages: ... classnames: ... xconf: ... What do you think? Quite frankly, I think changing implementation-specific names (packages, classes) is not worth the hassle. I'd change just the namespaces maybe, assuming they *might* be used for another implementation besides woody in the future, the block name and mostly the documentation. I don't mind keeping woody as the technical name in some places, IMHO the name change disruption is not worth it. Changing package or class names is the smallest problem if you use Eclipse ;-) ...I don't do the whole transformation at once because I know that I don't have enough time. So I hope that some others jump in hint/ ;-)... And that's a big problem, the risk of having a half-finished renaming is big if we aim too high. You could be right, so let's change the procedure: 1. create a new cforms block (BTW: I would set up the new block with the name: cforms) 2. move Java and Xconf files 3. check in into CVS 4. write the stylesheet 5. move the examples WDYT? Would be nice if somebody could help me with 4 and 5. Any takers? -- Reinhard
Re: From Woody to CocoonForms
Le Vendredi, 5 mars 2004, à 14:09 Europe/Zurich, Reinhard Pötz a écrit : ...Changing package or class names is the smallest problem if you use Eclipse ;-) sure, but what about docs, samples and people's minds ;-) ...I don't do the whole transformation at once because I know that I don't have enough time. So I hope that some others jump in hint/ ;-)... And that's a big problem, the risk of having a half-finished renaming is big if we aim too high. You could be right, so let's change the procedure: 1. create a new cforms block (BTW: I would set up the new block with the name: cforms) 2. move Java and Xconf files 3. check in into CVS 4. write the stylesheet 5. move the examples +1 and the idea is to delete the woody block once this works, right? -Bertrand
Re: From Woody to CocoonForms
Bertrand Delacretaz wrote: Le Vendredi, 5 mars 2004, à 14:09 Europe/Zurich, Reinhard Pötz a écrit : ...Changing package or class names is the smallest problem if you use Eclipse ;-) sure, but what about docs, samples and people's minds ;-) ...I don't do the whole transformation at once because I know that I don't have enough time. So I hope that some others jump in hint/ ;-)... And that's a big problem, the risk of having a half-finished renaming is big if we aim too high. You could be right, so let's change the procedure: 1. create a new cforms block (BTW: I would set up the new block with the name: cforms) 2. move Java and Xconf files 3. check in into CVS 4. write the stylesheet 5. move the examples +1 and the idea is to delete the woody block once this works, right? Yes -- Reinhard
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467. 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 13:37 --- tools subdirectory is done. Only one file was processed, I have reused the same ASF_20_SRC_AUTO tag on it. At this point all files which had an old license should have the 2.0 license, but we must check this. Seems like the committers/relicense/src/perl/insert_license.pl can do this check.
WOODY FREEZE! Was: From Woody to CocoonForms
Reinhard Pötz wrote: 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. First of all, let's freeze cocoon woody - so we do not loose any patches in the process, and it is easier to operate frozen woody... I propose to start WOODY FREEZE tomorrow morning - if you have good patches lying on your drive - commit them now :-) Before renaming namespaces. This should be a new block: woody block -- forms block Of course, this renaming has impact on many names and in order to avoid doing the same thing twice I want to here other opinions on this: namespaces: http://apache.org/cocoon/woody/definition/1.0 -- http://apache.org/cocoon/forms/definition/1.0 +1 packages: org.apache.cocoon.woody.transformation -- org.apache.cocoon.forms.transformation +1 classnames: AbstractWoodyAction -- AbstractCocoonFormsAction I suggest AbstractFormsAction. It's already in Cocoon, so no reason to mention it. xconf: woody-datatype logger=woody -- forms-datatype logger=forms +1 Vadim
Re: From Woody to CocoonForms
[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)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Turning off default MRU store
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.
So if the JCSStore includes a MRU-like memory front-end, it can simply
replace the store component in cocoon.xconf.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: From Woody to CocoonForms
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' (Hi Marc!) --Tim Larson
Re: WOODY FREEZE! Was: From Woody to CocoonForms
Vadim Gritsenko wrote: Reinhard Pötz wrote: 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. First of all, let's freeze cocoon woody - so we do not loose any patches in the process, and it is easier to operate frozen woody... I propose to start WOODY FREEZE tomorrow morning - if you have good patches lying on your drive - commit them now :-) Yes please. I don't start the tranformation before tomorrow afternoon. Before renaming namespaces. This should be a new block: woody block -- forms block yes. Of course, this renaming has impact on many names and in order to avoid doing the same thing twice I want to here other opinions on this: namespaces: http://apache.org/cocoon/woody/definition/1.0 -- http://apache.org/cocoon/forms/definition/1.0 +1 packages: org.apache.cocoon.woody.transformation -- org.apache.cocoon.forms.transformation +1 classnames: AbstractWoodyAction -- AbstractCocoonFormsAction I suggest AbstractFormsAction. It's already in Cocoon, so no reason to mention it. ok xconf: woody-datatype logger=woody -- forms-datatype logger=forms thanks Vadim! -- Reinhard
Re: From Woody to CocoonForms
[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: [CForms] Support for multipe unique-row-id in Repeater
Tim Larson wrote: On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater I also tend to prefer this approach - same reasoning with ambiguity of unique attribute. wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:on-bind wb:value id=myId1 path=myId1 unique=true/ wb:value id=myId2 path=myId2 unique=true/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater 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 wb:key... Oh, and I can suggest wb:identity - this will not have RDBMS background :-) Vadim
Re: From Woody to CocoonForms
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: Turning off default MRU store
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 store component in cocoon.xconf. My thoughts exactly
Re: From Woody to CocoonForms
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 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
[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: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/store JCSStore.java
[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 @@ * codegroup-name/code: the group to be used as defined in the config file */li * /ul - * + * + * 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: [cforms] Woody template transformer eating namespaced element tags?
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
XSLT test suite?
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] Support for multipe unique-row-id in Repeater
Vadim Gritsenko vadim at reverycodes.com writes: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater 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: wb:repeater wb:on-bind wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater And a fourth one is to specify values used for uniqueness independent on binding: wb:repeater wb:unique-row !-- here *no* binding happens! -- wb:element ref=myId1/ wb:element ref=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater 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
[SUMMARY] From Woody to Cocoon Forms 1.0
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: [SUMMARY] From Woody to Cocoon Forms 1.0
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: From Woody to CocoonForms
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
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 -- 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
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
RE: [SUMMARY] From Woody to Cocoon Forms 1.0
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 -- 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: [SUMMARY] From Woody to Cocoon Forms 1.0
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
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
[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
Marc Portier mpo at 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
DO NOT REPLY [Bug 27188] - CocoonPortlet default-encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27188. 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: [CForms] Support for multipe unique-row-id in Repeater
Joerg Heinicke wrote: Vadim Gritsenko vadim at reverycodes.com writes: wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:on-bind wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater 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: wb:repeater wb:on-bind wb:unique-row wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ /wb:unique-row wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater And a fourth one is to specify values used for uniqueness independent on binding: wb:repeater wb:unique-row !-- here *no* binding happens! -- wb:element ref=myId1/ wb:element ref=myId2/ /wb:unique-row wb:on-bind wb:value id=myId1 path=myId1/ wb:value id=myId2 path=myId2/ wb:value id=field1 path=field1/ wb:value id=field2 path=field2/ /wb:on-bind /wb:repeater 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-devm=107062679414114w=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]
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Joerg Heinicke wrote: Marc Portier mpo at 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: [SUMMARY] From Woody to Cocoon Forms 1.0
Vadim Gritsenko wrote: Joerg Heinicke wrote: Marc Portier mpo at 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]
Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)
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
Lastest from CVS 2.1.5-dev broken?
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 youre looking for faster http://search.yahoo.com
Re: Lastest from CVS 2.1.5-dev broken?
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
Re: Lastest from CVS 2.1.5-dev broken?
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 youre looking for faster http://search.yahoo.com
[portal] JSR168 portlets problems under PortalEngine
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
DO NOT REPLY [Bug 27456] - [PATCH] BetwixtTransformer output twice the startDocument. Fix.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27456. 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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
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 :)
Re: [RT] Cocoon Input Model
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 an own
Re: Momento and Cocoon [was Re: Jisp 3.0 moved to GPL licence]
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-23 15:21]:
snip/
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:
map:match pattern=index.html
map:generate type=momento src=momento.mx
xslt=index-document.xslt/
map:transform type=xslt src=document-to-web.xslt/
map:serialize type=html/
/map:match
(It is easier for me to express myself as a Cocoon user.)
I rather propose:
map:match pattern=index.html
map:generate type=xslt src=momento:mydocument.mx
xslt=index-document.xslt/
map:transform type=xslt src=document-to-web.xslt/
map:serialize type=html/
/map:match
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
Re: [RT] Cocoon Input Model
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 SQL
Re: [RT] Cocoon Input Model
Alan wrote: * Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 21:53]: snip/ 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=10402950241r=1w=2 and http://marc.theaimsgroup.com/?t=10413429892r=1w=2. New sitemap constructions? -- It can have a destination parameter where you can use a modifyable source,
RE: [portal] JSR168 portlets problems under PortalEngine
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: Lastest from CVS 2.1.5-dev broken?
--- 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 youre looking for faster http://search.yahoo.com
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
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: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)
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
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
Usage of SAXBuffer?
Hello, I want to write my own transformer which iterates over a element and repeates the content several times. For example: iterate times=3 pI'm the content/p /titerate The content pI'm the content/p should be repeated 3 times, like this: pI'm the content/p pI'm the content/p pI'm the content/p 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?
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
RE: Usage of SAXBuffer?
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
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:
iterate times=3
pI'm the content/p
/titerate
The content pI'm the content/p should be repeated 3 times, like
this:
pI'm the content/p
pI'm the content/p
pI'm the content/p
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
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
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
RE: SimpleFormTransformer (was: From Woody to CocoonForms)
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
Re: Usage of SAXBuffer?
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
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
DO NOT REPLY [Bug 27484] New: - NPE - Cocoon attempts to resolve input source incorrectly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484.
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-devm=107574604114201w=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:
map:call continuation={continuations:}/
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: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)
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
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
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: [SUMMARY] From Woody to Cocoon Forms 1.0
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: Usage of SAXBuffer?
Stephan Coboos wrote:
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
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: From Woody to CocoonForms
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: Cocoon Forms namespaces (was: [SUMMARY] From Woody to Cocoon Forms 1.0)
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
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: Experience with workflow at Hippo Webworks
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 after
DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484. 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.
DO NOT REPLY [Bug 27484] - NPE - Cocoon attempts to resolve input source incorrectly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484. 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.
Re: [SUMMARY] From Woody to Cocoon Forms 1.0
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 technical
DO NOT REPLY [Bug 18116] - VelocityGenerator property child elements don't take 'key' attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18116. 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 property 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
