Re: how can I build trunk?
Antonio Gallardo wrote:
The new cocoon uses maven 2. Download maven 2.0.2 [1], install it and
then follow the instructions [2]
I get the following error - should the deployer be disabled for now?
[INFO]
-
---
[INFO] Building Cocoon Block Deployer
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [castor:generate {execution: default}]
[INFO]
-
---
[ERROR] FATAL ERROR
[INFO]
-
---
[INFO] basedir src\main\resources\xsd does not exist
[INFO]
-
---
[INFO] Trace
java.lang.IllegalStateException: basedir src\main\resources\xsd does not
exist
at
org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:
542)
at
org.codehaus.plexus.compiler.util.scan.AbstractSourceInclusionScanner
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: M10N
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 18 Jan 2006, Reinhard Poetz wrote: Date: Wed, 18 Jan 2006 08:15:40 +0100 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: M10N Giacomo Pati wrote: Recently I was thinking about how we want our new build system to behave from a user perspective because I wanted to get the plugins going ASAP. Now I want to make sure that we all align on the same things. In general the build system of Cocoon 2.1.x was quite handy for most of us. ./buils.[sh|bat] ./cocoon.[sh|bat] Was all one needed to type to get a running system (yes some needed to adjust the local.[build|block].properties file but with M2 this should be doable in a similar but more Mavne-like way). Now, is it the goal of M10N to get as close to this as well? Or are we going to have different building procedures (mvn goals) depending on whether it is a component block, application block, webapp block, etc. M2 offers quite a lot of possibilities how to interact with its lifecycle/build phases so that building different types of artifacts could be standardized with our plugins which may be attached into those lifecycles/build phases. We can define our own artifact types so that there is possibilities to supply archetypes for things like application blocks, component blocks, abstract blocks, whatever and build them in a consistent way (from the users perspective), but package them as we need/like. I.e. = mvn # build the package depending on the artifact we # want to produce for a certain module (single modules # as well as multi module build) mvn cocoon:run # run it (independent whether this is the root or # a single module) WDYT? First contact with Cocoon - We can provide ready to use downloads that basically consist of - container (Jetty) - web application with blocks I think we need to do so. Cocoon is a complex thing and an effort giving an easy to install and use distribution to get in touch with it will be a must. We can also offer different sizes: - standard: contains the most important samples blocks (forms, template, auth, flowscript, javaflow) + all required blocks - portal: just the portal samples + all required blocks - full: all our samples + all required blocks Ok. These downloads are *not* the starting point for new Cocoon projects but only show the functionality. I know that. These download packages can also be used at cocoon.zones.apache.org for our live demos. I'm sure we can automate the packaging process in some way using the block deployer Maven plugin. BTW, I wouldn't even say these downloads are our _releases_ as IMO our releases are the block jars that we make available at our download pages and (more important!) via the Maven repositories. Correct. But I think we need a thing for first contact. Start your Cocoon project - As I said above, a Cocoon project is also a block. You create your block skeleton using the Maven block archetype, add your dependencies, e.g. your block depends on forms and template, and that's it. Yes, I see that, too. It's the same process as adding a Maven plugin to your pom.xml. You browse the Cocoon website and find a list of all available blocks. Than you add the required block to block.xml as requirement. As pointed out in the tutorial, you can use the cocoon:simple-deploy and jetty6:run to test-drive your block at development time. Ok. See http://cocoon.zones.apache.org/daisy/documentation/g2/796.html A Cocoon web application The cocoon:simple-deploy is only useful at development time as you don't have the possibility to change e.g. your web.xml and you can't use more than one block. Shouldn't it be you can't use more than _this_ block. This in contrary to the full blown sample distribution where all our samples blocks are independant (application) blocks which itself depend on (composition/service) blocks (i.e. like cron, or ajax which itself will be referenced by many of those independant blocks). Such a full blown sample distribution could well be a separate block in our repository just for building that distribution (at the ent it could be a war package). My plan is doing it the same way like other webapp projects. You provide your web application in /src/main/webapp which means that you put your web.xml there at least. Then you create your block-deploy.xml and you can say there which blocks you want to deploy, how they are configured and which implementations you want to use to fulfill their requirements. Fine. Do you have in mind to support this by a Maven plugin to create descriptors, based on dependencies defined in the pom, unpack them to create the webapp structure suitable for war packaging? See
Re: how can I build trunk?
Carsten Ziegeler wrote: Giacomo Pati wrote: On Tue, 17 Jan 2006, Ralph Goers wrote: Date: Tue, 17 Jan 2006 21:15:28 -0800 From: Ralph Goers [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org, [EMAIL PROTECTED] To: dev@cocoon.apache.org Subject: Re: how can I build trunk? We should probably remove build.sh If we remove build.sh we probably should remove lots of other things too (lib/, tools/) +1 If noone objects I'll remove all ant related stuff later today - I'll leave the libs for now as this directory helps in finding out dependencies. Once we have converted all blocks we should remove libs as well. +1 legal must also be kept, even when we remove lib, as there is no support for licence handling in Maven yet. Hopefully Maven can give automated support for licence handling when ASF get a common policy for where and how to put forign licenses in the distributions. /Daniel
Re: how can I build trunk?
Carsten Ziegeler wrote: Antonio Gallardo wrote: The new cocoon uses maven 2. Download maven 2.0.2 [1], install it and then follow the instructions [2] I get the following error - should the deployer be disabled for now? Yes, there is a bug in the the castor plugin that makes it read files relative current working directory rather than directory of pom.xml. This makes the deployer buildable only from its own directory, not from the top level. The deployer plugin must be disabled as well. /Daniel
Re: how can I build trunk?
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Giacomo Pati wrote: On Tue, 17 Jan 2006, Ralph Goers wrote: Date: Tue, 17 Jan 2006 21:15:28 -0800 From: Ralph Goers [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org, [EMAIL PROTECTED] To: dev@cocoon.apache.org Subject: Re: how can I build trunk? We should probably remove build.sh If we remove build.sh we probably should remove lots of other things too (lib/, tools/) +1 If noone objects I'll remove all ant related stuff later today - I'll leave the libs for now as this directory helps in finding out dependencies. Once we have converted all blocks we should remove libs as well. +1 legal must also be kept, even when we remove lib, as there is no support for licence handling in Maven yet. Hopefully Maven can give automated support for licence handling when ASF get a common policy for where and how to put forign licenses in the distributions. +1 as well. Let's remove the now broken and useless Ant build, but keep precious legal information accumulated over the years :-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: how can I build trunk?
* Ralph Goers: We should probably remove build.sh +1 I met the same issue trying to build trunk. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: how can I build trunk?
About Maven, I tried to mavenize the xmldb block and I can't get it to build because some POMs cannot be fetched. Can someone go into cocoon-xmldb and try to build? Also, I did not import the xmldb samples for now, I'll do it later when the implementation builds. So there is still a src/blocks/xmldb. It's half-baked because I had a lot of problems with Maven: 1) I had to download a snapshot because Maven 2.0.1 does not work 2) I had the error with XSD schema 3) Many POMs cannot be retrieved I have to restart build 20 times Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Requesting JIRA karma
Sorry to bug you, but this is urgent! I need to assign myself bugs to feel right. Is there only one person able to grant Jira karma? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [M10N] cocoon-jcr
David Nuescheler wrote: hi sylvain, does this help? http://www.day.com/maven/jsr170/licenses/day-spec-license.htm if i can do anything else to help, please let me know. it clearly is our intention that everybody should be able to redistribute the jcr-1.0.jar well, I will use your statement in front of a court (maybe in the future) to argue why we redistributed jcr-1.0.jar ;-) Although I am not sure if the word intention is enough versus the end of the second para: No license is granted hereunder for any other purpose (including, for example, modifying the Specification, other than to the extent of your fair use rights, or distributing the Specification to third parties) or am I misunderstanding something? Or what is the context of distributing the Specification to third parties? Thanks Michi regards, david -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Requesting JIRA karma
Le 18 janv. 06, à 10:08, Jean-Baptiste Quenot a écrit : Sorry to bug you, but this is urgent! I need to assign myself bugs to feel right. Is there only one person able to grant Jira karma? I think Pier has admin rights on Jira, dunno who else has. You might want to ask on infra@ -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: M10N
Giacomo Pati wrote:
BTW, I wouldn't even say these downloads are our _releases_ as IMO our
releases are the block jars that we make available at our download
pages and (more important!) via the Maven repositories.
Correct. But I think we need a thing for first contact.
Can you give an example for what you mean with first contract?
Start your Cocoon project
-
As I said above, a Cocoon project is also a block. You create your
block skeleton using the Maven block archetype, add your dependencies,
e.g. your block depends on forms and template, and that's it.
Yes, I see that, too.
It's the same process as adding a Maven plugin to your pom.xml. You
browse the Cocoon website and find a list of all available blocks.
Than you add the required block to block.xml as requirement.
As pointed out in the tutorial, you can use the cocoon:simple-deploy
and jetty6:run to test-drive your block at development time.
Ok.
See http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
A Cocoon web application
The cocoon:simple-deploy is only useful at development time as you
don't have the possibility to change e.g. your web.xml and you can't
use more than one block.
Shouldn't it be you can't use more than _this_ block. This in contrary
to the full blown sample distribution where all our samples blocks are
independant (application) blocks which itself depend on
(composition/service) blocks (i.e. like cron, or ajax which itself will
be referenced by many of those independant blocks). Such a full blown
sample distribution could well be a separate block in our repository
just for building that distribution (at the ent it could be a war package).
yes
My plan is doing it the same way like other webapp projects. You
provide your web application in /src/main/webapp which means that you
put your web.xml there at least.
Then you create your block-deploy.xml and you can say there which
blocks you want to deploy, how they are configured and which
implementations you want to use to fulfill their requirements.
Fine. Do you have in mind to support this by a Maven plugin to create
descriptors, based on dependencies defined in the pom, unpack them to
create the webapp structure suitable for war packaging?
pom.xml only contains the Java library dependencies. But yes, we could provide
some plugin that creates an initial block-deploy.xml if we see that we need this
- time will show.
See http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
Developing Cocoon (-- for Cocoon developers)
-
AFAIU there is no difference to developing an application block (I
even think that we should restrain from introducing this distinction.).
The difference is made up in the descriptors (i.e. has a sitemap, just
supplies some common components/services).
yes, that's an internal difference. A block can
- contain Java classes and a Cocoon app
- only Java classes
- only a Cocoon app
Looking at block.xml shows only two differences: Does it has a servlets
section and does it have a components section? At deployment time you don't
care which type of block it is internally.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: how can I build trunk?
Jean-Baptiste Quenot wrote: About Maven, I tried to mavenize the xmldb block and I can't get it to build because some POMs cannot be fetched. Can someone go into cocoon-xmldb and try to build? Also, I did not import the xmldb samples for now, I'll do it later when the implementation builds. So there is still a src/blocks/xmldb. It's half-baked because I had a lot of problems with Maven: 1) I had to download a snapshot because Maven 2.0.1 does not work I have no problems with 2.0.1. What specifically doesn't work. 2) I had the error with XSD schema The cocoon-deployer and cocoon-plugins must be disabled in the top level POM, if you refer to the problem that have been discussed earlier in this thread. 3) Many POMs cannot be retrieved I have to restart build 20 times The Apache local Maven repositories doesn't work that well, and generates intermitent cannot connect errors, IIRC. The solutions for this is: 1. Help moving artifacts that we use from the Apache repository to the much better and mirrored ibiblio repository, see http://maven.apache.org/project-faq.html. 2. Reduce the use of snapshot POMs. If you start building all of Cocoon from top level rather than from a specific block, you will use your own snapshots of the needed block instead of those from the snapshot repository. Especially if you change the top level POM or several blocks at once, this might be needed as the snapshot in the repository doesn't contain your latest changes (not completely sure about what policy maven has for downloading snapshots from the networked repositories rather than from your local). 3. Joining the infrastructure group and work for making the snapshot repository more stable ;) /Daniel
Re: Requesting JIRA karma
Bertrand Delacretaz schrieb: Le 18 janv. 06, à 10:08, Jean-Baptiste Quenot a écrit : Sorry to bug you, but this is urgent! I need to assign myself bugs to feel right. Is there only one person able to grant Jira karma? What's your JIRA ID? I can add you. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Requesting JIRA karma
Carsten Ziegeler schrieb: Bertrand Delacretaz schrieb: Le 18 janv. 06, à 10:08, Jean-Baptiste Quenot a écrit : Sorry to bug you, but this is urgent! I need to assign myself bugs to feel right. Is there only one person able to grant Jira karma? What's your JIRA ID? I can add you. You have two ids currently: jbq and [EMAIL PROTECTED] Which one should I use and can I delete the other one? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: M10N
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 18 Jan 2006, Reinhard Poetz wrote: Date: Wed, 18 Jan 2006 10:26:13 +0100 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: M10N Giacomo Pati wrote: BTW, I wouldn't even say these downloads are our _releases_ as IMO our releases are the block jars that we make available at our download pages and (more important!) via the Maven repositories. Correct. But I think we need a thing for first contact. Can you give an example for what you mean with first contract? A distribution that can be downloaded, unpacked, and started with all samples we have to give her the overview what Cocoon is, can do, and feels like. Start your Cocoon project - As I said above, a Cocoon project is also a block. You create your block skeleton using the Maven block archetype, add your dependencies, e.g. your block depends on forms and template, and that's it. Yes, I see that, too. It's the same process as adding a Maven plugin to your pom.xml. You browse the Cocoon website and find a list of all available blocks. Than you add the required block to block.xml as requirement. As pointed out in the tutorial, you can use the cocoon:simple-deploy and jetty6:run to test-drive your block at development time. Ok. See http://cocoon.zones.apache.org/daisy/documentation/g2/796.html A Cocoon web application The cocoon:simple-deploy is only useful at development time as you don't have the possibility to change e.g. your web.xml and you can't use more than one block. Shouldn't it be you can't use more than _this_ block. This in contrary to the full blown sample distribution where all our samples blocks are independant (application) blocks which itself depend on (composition/service) blocks (i.e. like cron, or ajax which itself will be referenced by many of those independant blocks). Such a full blown sample distribution could well be a separate block in our repository just for building that distribution (at the ent it could be a war package). yes My plan is doing it the same way like other webapp projects. You provide your web application in /src/main/webapp which means that you put your web.xml there at least. Then you create your block-deploy.xml and you can say there which blocks you want to deploy, how they are configured and which implementations you want to use to fulfill their requirements. Fine. Do you have in mind to support this by a Maven plugin to create descriptors, based on dependencies defined in the pom, unpack them to create the webapp structure suitable for war packaging? pom.xml only contains the Java library dependencies. But yes, we could provide some plugin that creates an initial block-deploy.xml if we see that we need this - time will show. And the wiring.xml I suppose. See http://cocoon.zones.apache.org/daisy/documentation/g2/797.html Developing Cocoon (-- for Cocoon developers) - AFAIU there is no difference to developing an application block (I even think that we should restrain from introducing this distinction.). The difference is made up in the descriptors (i.e. has a sitemap, just supplies some common components/services). yes, that's an internal difference. A block can - contain Java classes and a Cocoon app - only Java classes - only a Cocoon app Looking at block.xml shows only two differences: Does it has a servlets section and does it have a components section? At deployment time you don't care which type of block it is internally. Ok - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzhERLNdJvZjjVZARAlUAAKCqyElJqsdBvoVShcsFGN/0iHfKLQCgoPJc JJz9ueUMUxpLYzx6z2nW+bw= =9d+6 -END PGP SIGNATURE-
[Documented in Wiki] RE: Cocoon 2.1.8 and SendMailTransformer
-Original Message- From: Jasha Joachimsthal Sent: maandag 16 januari 2006 12:24 To: dev@cocoon.apache.org Subject: RE: Cocoon 2.1.8 and SendMailTransformer -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: vrijdag 13 januari 2006 19:02 To: dev@cocoon.apache.org Subject: Re: Cocoon 2.1.8 and SendMailTransformer Jasha Joachimsthal wrote: When I try to use the SendMailTransformer, it only tries to connect to localhost on port 25. After building, remove: geronimo-spec-javamail-1.3.1-rc5.jar geronimo-spec-activation-1.0.2-rc4.jar Then copy the mail.jar from sun and this works. The geronimo files are intended to be mock classes for compiled. They don't need to be used in production. I looked on the Cocoon site, the Cocoon Wiki and cocoon.zones.apache.org but couldn't find a general page about the SendMailTransformer to add this to the documentation. What is the best place to document this? I documented this feature in the Wiki http://wiki.apache.org/cocoon/SendMailTransformer Jasha Joachimsthal - Hippo Oosteinde 11 1017 WT Amsterdam The Netherlands +31 (0)20 5224466 [EMAIL PROTECTED] www.hippo.nl
[jira] Updated: (COCOON-1718) Ajax client library handling script tags
[ http://issues.apache.org/jira/browse/COCOON-1718?page=all ] Freek Segers updated COCOON-1718: - Attachment: patch_cocoon-ajax.js_1_1_8.txt This patch file was created using cvs diff on the original cocoon-ajax.js included with the Cocoon 1.1.8 release. I'm not sure if you can use this instead of a svn diff. Please let me know if you really need the svn diff. (I've never used svn.) Ajax client library handling script tags Key: COCOON-1718 URL: http://issues.apache.org/jira/browse/COCOON-1718 Project: Cocoon Type: Improvement Components: Blocks: Ajax Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Freek Segers Attachments: cocoon-ajax.js, patch_cocoon-ajax.js_1_1_8.txt The way Ajax currently handles script tags in browser updates, the scripts are evaluated before the HTML elements are replaced. Because scripts may call for example document.getElementById() they act on the old elements, that are replaced later on. It would be better to evaluate the scripts after the element has been replaced. The attached file contains a few overridden functions from from the default cocoon-ajax.js file to postpone script evaluation until after element replacement. I'm still investigating a possible problem with IE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Requesting JIRA karma
* Carsten Ziegeler: You have two ids currently: jbq and [EMAIL PROTECTED] Which one should I use and can I delete the other one? I have three profiles: jbq [EMAIL PROTECTED] [EMAIL PROTECTED] The first one is the right one. You can delete the other ones. Thanks in advance! -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: M10N
Giacomo Pati wrote:
Fine. Do you have in mind to support this by a Maven plugin to create
descriptors, based on dependencies defined in the pom, unpack them to
create the webapp structure suitable for war packaging?
pom.xml only contains the Java library dependencies. But yes, we could
provide some plugin that creates an initial block-deploy.xml if we see
that we need this - time will show.
And the wiring.xml I suppose.
Of course it's possible to edit the wiring.xml but I would (will) recommend
using the deployer as it will do validation, auto-wiring, ...
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Requesting JIRA karma
Jean-Baptiste Quenot wrote: * Carsten Ziegeler: You have two ids currently: jbq and [EMAIL PROTECTED] Which one should I use and can I delete the other one? I have three profiles: jbq [EMAIL PROTECTED] [EMAIL PROTECTED] The first one is the right one. You can delete the other ones. Ok, I added the first one to the cocoon group. I can't delete the other two ones as some issues are assigned to them. Can you please assign the issues to your first profile, then I can delete the other two. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: M10N
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 18 Jan 2006, Reinhard Poetz wrote: Date: Wed, 18 Jan 2006 11:30:00 +0100 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: M10N Giacomo Pati wrote: Fine. Do you have in mind to support this by a Maven plugin to create descriptors, based on dependencies defined in the pom, unpack them to create the webapp structure suitable for war packaging? pom.xml only contains the Java library dependencies. But yes, we could provide some plugin that creates an initial block-deploy.xml if we see that we need this - time will show. And the wiring.xml I suppose. Of course it's possible to edit the wiring.xml but I would (will) recommend Editing wiring.xml? I may now be totally wrong but I've understud that the wiring.xml is a generated file by the deployer (and the deployer-plugin uses the deployer). Please correct me if I'm wrong. using the deployer as it will do validation, auto-wiring, ... Actually I think I'm quite confused about all those descriptors described in our Daisy and what the actual code looks like. pom.xml - for Maven build - used by deployer-plugin to resolve dependencies(?) block.xml - describes a block (components, sitemap, properties) - is used by blocks framework block-deploy.xml - defines block dependencies for deployer(-plugin) - supplies additional information (i.e. values for block properties) - is used by deployer-plugin to create the wiring.xml (?) wiring.xml - configures a Cocoon app concerning block relationship, mount point, etc. Please correct if I'm wrong. I'm not quite sure the difference between block-deploy.xml and wiring.xml. Is it that wiring.xml is the sum of all block-deploy.xml and their connections? Can you describe how you see all those descriptors look like for our super-sample-block (collection of all block samples) will look like? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDziM4LNdJvZjjVZARApohAJ47a2kfFXeG8qPrWHNBHPF4gRktTwCfRUuj gLOiSQ6XQxQoaV3IDx0JGYM= =uJDf -END PGP SIGNATURE-
[jira] Assigned: (COCOON-1720) Form.js overwrites the CFormsInstance attribute
[ http://issues.apache.org/jira/browse/COCOON-1720?page=all ] Jean-Baptiste Quenot reassigned COCOON-1720: Assign To: Jean-Baptiste Quenot Form.js overwrites the CFormsInstance attribute --- Key: COCOON-1720 URL: http://issues.apache.org/jira/browse/COCOON-1720 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: 20051214-Form.js In Form.js the function showForm() stores the form in an attribute of the viewdata (the optional JS object passed by the user) called CFormsInstance . When invoking showForm() on two different forms but with the same viewdata, Form.js overwrites the attribute in viewdata. When resuming the continuation of the first form, an error occurs because the second form is referenced in the viewdata, and of course it doesn't have the same set of widgets. In other words: when the flow attributes are shared across multiple showForm(), Form.js overwrites the CFormsInstance attribute, which causes failure when reactivating the continuation of a previous screen. Please see attached patch: the solution is to make a copy of the JS object. *** There's also an improvement possible in Form.js provided in the same patch: to add a sendForm() function that does the same as showForm() except that no continuation is produced, to simplify development when no continuation is needed, and to reduce memory usage. *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1719) IncludeTransformer: source must not be cached if an error occurs
[ http://issues.apache.org/jira/browse/COCOON-1719?page=all ] Jean-Baptiste Quenot reassigned COCOON-1719: Assign To: Jean-Baptiste Quenot IncludeTransformer: source must not be cached if an error occurs Key: COCOON-1719 URL: http://issues.apache.org/jira/browse/COCOON-1719 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Critical Attachments: 20051220-IncludeTransformer When IncludeTransformer retrieves data from included sources, an error may occur. In this case, the error is propagated, but the transformation cannot be recovered until Cocoon is restarted or the pipeline changes. This is due to the fact that IncludeTransformer does not remove the validity object when an error is thrown. Note: when an error has occured, subsequent transformations return the cinclude:include XML element as-is in the result of the transformation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1707) Allow configuration of initial context in LDAPTransformer
[ http://issues.apache.org/jira/browse/COCOON-1707?page=all ] Jean-Baptiste Quenot reassigned COCOON-1707: Assign To: Jean-Baptiste Quenot Allow configuration of initial context in LDAPTransformer - Key: COCOON-1707 URL: http://issues.apache.org/jira/browse/COCOON-1707 Project: Cocoon Type: Improvement Components: Blocks: Naming Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-LDAPTransformer LDAPTransformer does not currently provide a way to specify the attributes in the initial context. Credit goes to Sébastien Grimault [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1706) Allow TeeTransformer tu run a system command for debugging purposes
[ http://issues.apache.org/jira/browse/COCOON-1706?page=all ] Jean-Baptiste Quenot reassigned COCOON-1706: Assign To: Jean-Baptiste Quenot Allow TeeTransformer tu run a system command for debugging purposes --- Key: COCOON-1706 URL: http://issues.apache.org/jira/browse/COCOON-1706 Project: Cocoon Type: Improvement Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-naming-TeeTransformer Hello, The TeeTransformer is great, but it would be still greater if it could run a system command every time it is invoked, to ease debugging of a Cocoon application. The system command can be eg vi, emacs, put your favorite editor here, so that every time the pipeline is executed, your editor pops up. Credit goes to Philippe Gassmann [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ http://issues.apache.org/jira/browse/COCOON-1622?page=all ] Jean-Baptiste Quenot reassigned COCOON-1622: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: http://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Jean-Baptiste Quenot Fix For: 2.1.9-dev (current SVN) Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Requesting JIRA karma
* Carsten Ziegeler: Ok, I added the first one to the cocoon group. I can't delete the other two ones as some issues are assigned to them. Can you please assign the issues to your first profile, then I can delete the other two. OK, Thanks a lot. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: how can I build trunk?
* Daniel Fagerstrom: 2) I had the error with XSD schema The cocoon-deployer and cocoon-plugins must be disabled in the top level POM, if you refer to the problem that have been discussed earlier in this thread. Someone commented out those two blocks, great. 3) Many POMs cannot be retrieved I have to restart build 20 times The Apache local Maven repositories doesn't work that well, and generates intermitent cannot connect errors, IIRC. The solutions for this is: 1. Help moving artifacts that we use from the Apache repository to the much better and mirrored ibiblio repository, see http://maven.apache.org/project-faq.html. 2. Reduce the use of snapshot POMs. If you start building all of Cocoon from top level rather than from a specific block, you will use your own snapshots of the needed block instead of those from the snapshot repository. Especially if you change the top level POM or several blocks at once, this might be needed as the snapshot in the repository doesn't contain your latest changes (not completely sure about what policy maven has for downloading snapshots from the networked repositories rather than from your local). 3. Joining the infrastructure group and work for making the snapshot repository more stable ;) Don't know the best solution, I will think about it. I added the cocoon-databases and cocoon-databases-mocks artifacts, to try and build cocoon-xmldb successfully. Here is my error: [INFO] Failed to resolve artifact. required artifacts missing: d-haven-managed-pool:d-haven-managed-pool:jar:1.0 for the artifact: org.apache.cocoon:cocoon-databases:jar:1.0-SNAPSHOT from the specified remote repositories: apache-maven2 (http://cvs.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), maven-snapshot (http://snapshots.maven.codehaus.org/maven2/), apache-cvs (http://cvs.apache.org/repository) How to fix that? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
[jira] Assigned: (COCOON-1715) [PATCH] Allow ContinuationsManagerImpl to run in CLI
[ http://issues.apache.org/jira/browse/COCOON-1715?page=all ] Jean-Baptiste Quenot reassigned COCOON-1715: Assign To: Jean-Baptiste Quenot [PATCH] Allow ContinuationsManagerImpl to run in CLI Key: COCOON-1715 URL: http://issues.apache.org/jira/browse/COCOON-1715 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: 20051216-continuationsmanager, contierror Build Cocoon without any block. When starting Cocoon with cocoon.sh cli there is an error: NoClassDefFoundError javax/servlet/http/HttpSessionBindingListener, see error log attached. The attached patch fixes this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
New skin for web site
When we were doing the work to generate the Docs from Daisy some people showed an interest in developing a new skin for the Cocoon site. Those people may be interested to know that I recently developed a skin to mimic the look and feel at http://www.apache.org This is a much simpler skin, much cleaner and much easier to modify. It is *not* complete. I am not a CSS expert and I have not done any checks in different browsers. But it's a good start I created two versions of this skin, one for the old Forrest skins system and one for the upcoming themes system. The theme is more complete and, is without a doubt, easier to customise. But it is also using code that is less mature (it is unlikely to be in the next Forrest release). This prompts two questions: 1) Should I create an instance in the Forrest Zone that builds the 2.2 docs using this new ASF theme so that it can be used as a base for a new Cocoon theme. 2) are there any web designers here willing to work on the skin (you don't need to learn how to get it into Forrest at first, just provide CSS patches and I'll integrate with Forrest for you - you'll quickly see how it is done) NOTE: since this uses in development code it is likely that the build will break on occasion. I doubt this is a problem for 2.2 docs, but if it is a concern we can use the existing skinning system rather than the dispatcher. Personally I would prefer to use the dispatcher as it is easier to customise and will provide useful feedback for the Forrest devs. It is likely the dispatcher will be ready for release at around the same time as Cocoon 2.2 (I'm not sure how can I possibly know that in Open Source projects though) Ross
[jira] Created: (COCOON-1734) Forms library not honouring cross-referencing classes
Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assigned to: Max Pfingsthorn See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1705) LDAPTransformer fails with NPE on attribute change - work fine on 2.1.5.1
[ http://issues.apache.org/jira/browse/COCOON-1705?page=all ] Jean-Baptiste Quenot updated COCOON-1705: - Waiting for your feedback to test the attached patch LDAPTransformer fails with NPE on attribute change - work fine on 2.1.5.1 - Key: COCOON-1705 URL: http://issues.apache.org/jira/browse/COCOON-1705 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Warrell Harries Attachments: 20060117-cocoon-ldaptr-exec_element The following works OK on 2.1.5.1 :- ?xml version=1.0 encoding=ISO-8859-1? ldapuser xmlns:ldap=http://apache.org/cocoon/LDAP/1.0; ldap:execute-replace ldap:initializercom.sun.jndi.ldap.LdapCtxFactory/ldap:initializer ldap:version3/ldap:version ldap:serverurlldap://ldap.westsussex.gov.uk/ldap:serverurl ldap:searchbaseou=training,ou=IRT,ou=apps,o=wscc,dc=westsussex,dc=gov,dc=uk/ldap:searchbase ldap:rootdncn=root/ldap:rootdn ldap:passwordpassw0rd/ldap:password ldap:count-limit0/ldap:count-limit ldap:time-limit0/ldap:time-limit ldap:filter(amp;(uid=irttraining02))/ldap:filter ldap:attribute name=givennametwo/ldap:attribute /ldap:execute-replace /ldapuser but fails with NPE on 2.1.8 java.lang.NullPointerException at org.apache.cocoon.transformation.LDAPTransformer$LDAPQuery.execute(LDAPTransformer.java:1264) at org.apache.cocoon.transformation.LDAPTransformer.executeQuery(LDAPTransformer.java:249) at org.apache.cocoon.transformation.LDAPTransformer.endExecuteElement(LDAPTransformer.java:288) at org.apache.cocoon.transformation.LDAPTransformer.endElement(LDAPTransformer.java:781) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:334) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:325) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:115) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:578) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at
[jira] Assigned: (COCOON-1693) When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html
[ http://issues.apache.org/jira/browse/COCOON-1693?page=all ] Jean-Baptiste Quenot reassigned COCOON-1693: Assign To: Jean-Baptiste Quenot When using src parameter on sendMail action, body is included as attachment, and when using body parameter, mimeType is always text/html Key: COCOON-1693 URL: http://issues.apache.org/jira/browse/COCOON-1693 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8 Reporter: Marc Salvetti Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: MailMessageSender.java, MailSender.java, Sendmail.java If using the src parameter, the body is included as an attachment (the header Content-disposition=attachment) is set. Moreover, when trying to stick some html in the body parameter, the mimeType is always text/html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1714) repeater min-size does not prevent removal of rows below minium size
[ http://issues.apache.org/jira/browse/COCOON-1714?page=all ] Jean-Baptiste Quenot updated COCOON-1714: - Waiting for a patch repeater min-size does not prevent removal of rows below minium size Key: COCOON-1714 URL: http://issues.apache.org/jira/browse/COCOON-1714 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Reporter: Eric Meyer repeater min-size does not prevent removal of rows below minium size e.g. fd:repeater id=industryStructure initial-size=1 min-size=1 I can remove all the rows and submit. Shouldn't min-size keep it from ever having fewer than those rows, or does this only cause a validation error. If the latter, then how is this error displayed? Regards, Eric -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
[ http://issues.apache.org/jira/browse/COCOON-1685?page=all ] Jean-Baptiste Quenot updated COCOON-1685: - Waiting for an example Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent - Key: COCOON-1685 URL: http://issues.apache.org/jira/browse/COCOON-1685 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Simone Gianni In the Form.process() method, there is a listener.phaseEnded on line 296 which sends a LOAD_MODEL_VALUE the first time the form is executed, and a READ_FROM_REQUEST_VALUE all the other times. If a ProcessingPhaseListener is registered it will receive a READ_FROM_REQUEST_VALUE before the request has been processed, and another one after. IMMO there are the following possible solutions : - remove this event broadcast. - send this event only if phase is LOAD_MODEL_VALUE, so that this event takes his chance to get broadcasted, while the spurious one doesn't. - add a PROCESS_INITIALIZED phase event and send this one at this point. I can produce the patch if needed, but don't know which solution is the best one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1711) [PATCH] correct position of help popup for tab styling
[ http://issues.apache.org/jira/browse/COCOON-1711?page=all ]
Jean-Baptiste Quenot updated COCOON-1711:
-
Thanks for your contribution. Can you please attach a testcase? With HTML
output before applying your patch and after applying it? This will help us to
qualify this issue.
[PATCH] correct position of help popup for tab styling
--
Key: COCOON-1711
URL: http://issues.apache.org/jira/browse/COCOON-1711
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.9-dev (current SVN)
Reporter: Werner Masik
Priority: Minor
Attachments: forms-advanced-field-styling.xsl.diff
Help popups appear in the wrong position when the tab styling is used.
Usually it pops up below the div that contains the tabbed form, which means
that the popup is often outside of the visible viewing area.
Looks like the bug exists since the stylesheets of 2.1.7 and dev branch were
merged.
The problem is that the function forms_createPopupWindow does not get called
when
the page is loaded into the browser. In current 2.1.X branch the function
gets called
directly from the a href= ...
a
onclick=forms_createPopupWindow('email:help').showPopup('email:help:a');return
false; href=# name=email:help:a id=email:help:aimg alt=helppopup
src=resources/forms/img/help.gif/a
So the function is executed when then link to the popup is clicked.
In 2.1.7 it was called like this:
script type=text/javascript
var helpWinN1003B = forms_createPopupWindow('helpN1003B');
/script
a onclick=helpWinN1003B.showPopup('N1003B');return false; href=#
name=N1003B id=N1003Bimg alt=helppopup src=/images/help.gif/a
Here the popup window was created at the first display of the browser page.
Actually when in tab-styling the whole popup-tree was just copied right below
the body-tag because of the positioning issues. This was done
with the forms_moveInBody function which was called in the onload handler of
the forms.
Therefore 2 possible solutions exist:
- revert the code to the old version, to register the handler before the
onload is executed
- alter forms-advanced-field-styling.xsl so the divs for the popups are all
created as a child of the body tag
The patch I'm submitting takes the second aproach. All it does is create the
divs where they should be
from the beginning (below body). This is done by introducing a mode called
'forms-help', to make the fi:help
tags get processed twice. In the first run the divs are created and in the
second run links for the popups
are created just behind the field (as usual). Moving the divs with
javascript therefore becomes obsolete. I think
that registering the onloadHanlder to call forms_moveInBody can be removed.
But I was not sure if
it is needed for something else, so I kept it.
I'm not a XSLT expert. There might be a better way to process the help
popups. Feel free
to make corrections. I also have no experience with ajax. I tested it with
ajax activated
and it worked. But I'm not sure if my test was using ajax the right way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1729) [PATCH] Add multiple rows to a Repeater (fd:repeater-action).
[ http://issues.apache.org/jira/browse/COCOON-1729?page=all ] Jean-Baptiste Quenot reassigned COCOON-1729: Assign To: Jean-Baptiste Quenot [PATCH] Add multiple rows to a Repeater (fd:repeater-action). - Key: COCOON-1729 URL: http://issues.apache.org/jira/browse/COCOON-1729 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.8 Reporter: Rolf Metternich Assignee: Jean-Baptiste Quenot Priority: Trivial Attachments: patch.txt To add a certain numbers of Repeater.Rows (more than 1) to a Repeater with one Action, use the attribute number-of-rows in the definition of a repeater-action. Example: fd:repeater-action command=add-row id=add-many-rows-to-repeater number-of-rows=5 repeater=repeater-name fd:label Add 5 rows/fd:label /fd:repeater-action fd:repeater-action command=add-row id=add-one-row-to-repeater repeater=repeater-name fd:labelAdd 1 row/fd:label /fd:repeater-action -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1695) Saxon requires an XML parser that reports the QName of each element
[ http://issues.apache.org/jira/browse/COCOON-1695?page=all ] Jean-Baptiste Quenot reassigned COCOON-1695: Assign To: Jean-Baptiste Quenot Saxon requires an XML parser that reports the QName of each element --- Key: COCOON-1695 URL: http://issues.apache.org/jira/browse/COCOON-1695 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Assignee: Jean-Baptiste Quenot Attachments: patch.txt The default AbstractTextSerializer attempts to detect whether the wrapped TransformerFactory supports encoding namespaces by iteself by simply passing the namespace declaration in startPrefixMapping(..) or requires them to be hardcoded into attributes. When Saxon is the default XSLT transformer factory, every time an instance of an AbstractTextSerializer is created, this exception crops up: [2005/11/22 21:39:08.193] WARN [xml] Cannot know if transformer needs namespaces attributes - assuming NO. org.xml.sax.SAXException: Saxon requires an XML parser that reports the QName of each element at net.sf.saxon.event.ReceivingContentHandler.getNameCode(ReceivingContentHandler.java:264) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:194) at org.apache.cocoon.serialization.AbstractTextSerializer.needsNamespacesAsAttributes(AbstractTextSerializer.java:333) at org.apache.cocoon.serialization.AbstractTextSerializer.configure(AbstractTextSerializer.java:257) at org.apache.cocoon.serialization.XMLSerializer.configure(XMLSerializer.java:41) at org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.newPoolable(InstrumentedResourceLimitingPool.java:655) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.get(InstrumentedResourceLimitingPool.java:371) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doGet(PoolableComponentHandler.java:198) at org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:381) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:215) at org.apache.cocoon.components.ExtendedComponentSelector.select(ExtendedComponentSelector.java:262) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setSerializer(AbstractProcessingPipeline.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:679) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.mortbay.jetty.servlet.ServletHolder.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Unknown Source) at org.mortbay.jetty.servlet.ServletHandler.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.jetty.servlet.WebApplicationContext.handle(Unknown Source) at org.mortbay.http.HttpContext.handle(Unknown Source) at org.mortbay.http.HttpServer.service(Unknown Source) at org.mortbay.http.HttpConnection.service(Unknown Source) at org.mortbay.http.HttpConnection.handleNext(Unknown Source) at org.mortbay.http.HttpConnection.handle(Unknown Source) at
[jira] Assigned: (COCOON-1698) [PATCH] caching-global-use-attributes does not work
[ http://issues.apache.org/jira/browse/COCOON-1698?page=all ] Jean-Baptiste Quenot reassigned COCOON-1698: Assign To: Jean-Baptiste Quenot [PATCH] caching-global-use-attributes does not work --- Key: COCOON-1698 URL: http://issues.apache.org/jira/browse/COCOON-1698 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Guillaume Déflache Assignee: Jean-Baptiste Quenot Attachments: CachingURICopletAdapter.java.diff Global cache using attributes does not work: an event on a coplet instance always delete the corresponding cache entry. In fact a coplet instance event only allows to modify the coplet instance attributes. However all the attributes are part of the cache key. So modify them must make no cache entry invalid but must lead to the creation of a new entry. Included patch fixes just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1718) Ajax client library handling script tags
[ http://issues.apache.org/jira/browse/COCOON-1718?page=all ] Jean-Baptiste Quenot reassigned COCOON-1718: Assign To: Jean-Baptiste Quenot Ajax client library handling script tags Key: COCOON-1718 URL: http://issues.apache.org/jira/browse/COCOON-1718 Project: Cocoon Type: Improvement Components: Blocks: Ajax Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Freek Segers Assignee: Jean-Baptiste Quenot Attachments: cocoon-ajax.js, patch_cocoon-ajax.js_1_1_8.txt The way Ajax currently handles script tags in browser updates, the scripts are evaluated before the HTML elements are replaced. Because scripts may call for example document.getElementById() they act on the old elements, that are replaced later on. It would be better to evaluate the scripts after the element has been replaced. The attached file contains a few overridden functions from from the default cocoon-ajax.js file to postpone script evaluation until after element replacement. I'm still investigating a possible problem with IE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: how can I build trunk?
Jean-Baptiste Quenot wrote: ... Don't know the best solution, I will think about it. I added the cocoon-databases and cocoon-databases-mocks artifacts, to try and build cocoon-xmldb successfully. Here is my error: [INFO] Failed to resolve artifact. required artifacts missing: d-haven-managed-pool:d-haven-managed-pool:jar:1.0 for the artifact: org.apache.cocoon:cocoon-databases:jar:1.0-SNAPSHOT from the specified remote repositories: apache-maven2 (http://cvs.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), maven-snapshot (http://snapshots.maven.codehaus.org/maven2/), apache-cvs (http://cvs.apache.org/repository) How to fix that? You find instructions in the end of http://cocoon.zones.apache.org/daisy/documentation/g2/756.html. Now I'm a little bit suprized that it is missing, IIRC, that jar is used in the Excalibur project, and Jorg worked together with Excalibur to move Excalibur to M2. Hopefully Jorg can comment. Otherwise, the best long term solution is to ask d-haven.org (i.e. Berin Loritsch, IIUC), to publish their artifacts on the central maven2 repository. /Daniel
[jira] Assigned: (COCOON-1621) error in forms samples
[ http://issues.apache.org/jira/browse/COCOON-1621?page=all ] Jean-Baptiste Quenot reassigned COCOON-1621: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) error in forms samples -- Key: COCOON-1621 URL: http://issues.apache.org/jira/browse/COCOON-1621 Project: Cocoon Type: Bug Components: - Samples Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Jean-Baptiste Quenot Validation rule value-count cannot be used with strings, error at file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml:115:38 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 Error calling flowscript function example file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38[Exception] resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js - 53:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 27:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 22:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/sitemap.xmap - 68:39 map:call file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/sitemap.xmap - 575:65map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/sitemap.xmap - 66:68 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/sitemap.xmap - 194:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/sitemap.xmap - 663:66 map:mount -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1621) Cannot use a fd:value-count validation rule with fd:multivaluefield
[ http://issues.apache.org/jira/browse/COCOON-1621?page=all ] Jean-Baptiste Quenot updated COCOON-1621: - Bugzilla Id: (was: 36946) Component: Blocks: Forms (was: - Samples) Summary: Cannot use a fd:value-count validation rule with fd:multivaluefield (was: error in forms samples) Description: Validation rule value-count cannot be used with strings, error at file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml:115:38 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 Error calling flowscript function example file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 [Exception] resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js - 53:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 27:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 22:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/sitemap.xmap - 68:39 map:call file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/sitemap.xmap - 575:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/sitemap.xmap - 66:68 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/sitemap.xmap - 194:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/sitemap.xmap - 663:66map:mount was: Validation rule value-count cannot be used with strings, error at file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml:115:38 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 Error calling flowscript function example file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 [Exception] resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js - 53:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 27:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 22:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/sitemap.xmap - 68:39 map:call file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/sitemap.xmap - 575:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/sitemap.xmap - 66:68 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/sitemap.xmap - 194:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/sitemap.xmap - 663:66map:mount Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Cannot use a fd:value-count validation rule with fd:multivaluefield --- Key: COCOON-1621 URL: http://issues.apache.org/jira/browse/COCOON-1621 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN), 2.2-dev (Current SVN), 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Jean-Baptiste Quenot Validation rule value-count cannot be used with strings, error at file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml:115:38 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 Error calling flowscript function example file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38[Exception] resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js - 53:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 27:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 22:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/sitemap.xmap - 68:39 map:call file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/sitemap.xmap - 575:65map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/sitemap.xmap - 66:68 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/sitemap.xmap - 194:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/sitemap.xmap - 663:66 map:mount -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: how can I build trunk?
Daniel Fagerstrom wrote You find instructions in the end of http://cocoon.zones.apache.org/daisy/documentation/g2/756.html. Now I'm a little bit suprized that it is missing, IIRC, that jar is used in the Excalibur project, and Jorg worked together with Excalibur to move Excalibur to M2. Hopefully Jorg can comment. Otherwise, the best long term solution is to ask d-haven.org (i.e. Berin Loritsch, IIUC), to publish their artifacts on the central maven2 repository. Or we can exclude them as we don't need the d-haven implementation. With ECM++ we use our own stuff. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Closed: (COCOON-1621) Cannot use a fd:value-count validation rule with fd:multivaluefield
[ http://issues.apache.org/jira/browse/COCOON-1621?page=all ] Jean-Baptiste Quenot closed COCOON-1621: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed AFAICT Marco's patch fixes the problem perfectly. Cannot use a fd:value-count validation rule with fd:multivaluefield --- Key: COCOON-1621 URL: http://issues.apache.org/jira/browse/COCOON-1621 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN), 2.2-dev (Current SVN), 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Jean-Baptiste Quenot Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Validation rule value-count cannot be used with strings, error at file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml:115:38 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38 Error calling flowscript function example file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/form1.xml - 115:38[Exception] resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js - 53:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 27:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/forms_flow_example.js - 22:-1 file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/v2/sitemap.xmap - 68:39 map:call file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/forms/sitemap.xmap - 575:65map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/blocks/sitemap.xmap - 66:68 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/samples/sitemap.xmap - 194:65 map:mount file:/D:/src/cocoon-2.1.x/build/webapp/sitemap.xmap - 663:66 map:mount -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 55 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-18012006.jar -Dbuild=build/cocoon-18012006 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 55 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-18012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-18012006.jar -Dbuild=build/cocoon-18012006 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[jira] Assigned: (COCOON-1627) [PATCH] Permit the choice of attributes to augment in AugmentTransformer
[ http://issues.apache.org/jira/browse/COCOON-1627?page=all ] Jean-Baptiste Quenot reassigned COCOON-1627: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) [PATCH] Permit the choice of attributes to augment in AugmentTransformer Key: COCOON-1627 URL: http://issues.apache.org/jira/browse/COCOON-1627 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Aurélien DEHAY Assignee: Jean-Baptiste Quenot Attachments: diff Here is a patch againt 2.1.7 version augment transformer which add a attributes parameter which permit to choose the attributes to be augmented. Defaults to href if the parameter is not set: map:transform type=augment map:parameter name=attributes value=href src/ /map:transform Useful, for example, for script type=text/javascript src=path/to/js.js/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1627) [PATCH] Permit the choice of attributes to augment in AugmentTransformer
[ http://issues.apache.org/jira/browse/COCOON-1627?page=all ] Jean-Baptiste Quenot closed COCOON-1627: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Committed, thanks for your contribution! See http://svn.apache.org/viewcvs.cgi?rev=370146view=rev [PATCH] Permit the choice of attributes to augment in AugmentTransformer Key: COCOON-1627 URL: http://issues.apache.org/jira/browse/COCOON-1627 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Aurélien DEHAY Assignee: Jean-Baptiste Quenot Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Attachments: diff Here is a patch againt 2.1.7 version augment transformer which add a attributes parameter which permit to choose the attributes to be augmented. Defaults to href if the parameter is not set: map:transform type=augment map:parameter name=attributes value=href src/ /map:transform Useful, for example, for script type=text/javascript src=path/to/js.js/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
NPE in AbstractWidgetDefinition when using library
Hola, I'm using forms library from svn updated some minutes ago, if I extend a field from library I got a NPE at row 92 of AbstractWidgetDefinition because the property attributes is null, probably this map was never initialized. My library is this: ... fd:field id=account required=true fd:labeli18n:textlabel.account/i18n:text/fd:label fd:datatype base=string/ fd:selection-list src=cocoon:/common/accounts/ /fd:field ... and my definition: ... fd:field id=account extends=lib:account fd:on-value-changed fd:javascript print(on-value-changed); /fd:javascript /fd:on-value-changed /fd:field ... other widget work correctly and if I expand this instead of extend it work. Any hint? TIA -- Daniele Madama (http://www.danysoft.org) Pro-netics S.r.l. (http://www.pronetics.it)
[jira] Closed: (COCOON-1610) [PATCH] add id's to cforms validation messages and errors
[ http://issues.apache.org/jira/browse/COCOON-1610?page=all ] Jean-Baptiste Quenot closed COCOON-1610: Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) The patch has been rewritten and committed, thanks for your contribution. See http://svn.apache.org/viewcvs.cgi?rev=370150view=rev [PATCH] add id's to cforms validation messages and errors - Key: COCOON-1610 URL: http://issues.apache.org/jira/browse/COCOON-1610 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.7 Environment: Operating System: other Platform: Other Reporter: Thomas Lutz Assignee: Jean-Baptiste Quenot Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Attachments: forms-field-styling.xsl.tar.gz Adds id to cform validation messages, so that they can be tested with something like httpunit or jwebunit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1609) form binding ambiguity creating new paths
[ http://issues.apache.org/jira/browse/COCOON-1609?page=all ] Jean-Baptiste Quenot updated COCOON-1609: - Please provide a testcase demonstrating the problem. Also you may review this change: When saving a cform, remove xml elements if the value of the widget is null https://issues.apache.org/jira/browse/COCOON-1687 And if you could send a patch, this would allow to address the issue in a more timely manner. Thanks in advance. form binding ambiguity creating new paths -- Key: COCOON-1609 URL: http://issues.apache.org/jira/browse/COCOON-1609 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Stefan Podkowinski Assignee: Cocoon Developers Team The current way cform binding is handled is a bit confusing regarding the creation of new (jx)path elements. While fb:value works (to me) as expected, other bindings behave quite different. E.g. the following binding would create the given path if non-existing. fb:value id=form.test path=/test/hello / Others, such as fb:set-attribute or fb:custom would not and throw an exception given the path above. This must be due the fact that the doSave() method of each binding class is implemented differently. The ValueJXPathBinding class calls createPathAndSetValue() while others expect that the given path does already exist calling getRelativeContext() directly. This behaviour is especially annoying for fb:custom bindings in my case. See also: http://issues.apache.org/bugzilla/show_bug.cgi?id=30693 http://www.mail-archive.com/dev@cocoon.apache.org/msg20645.html fb:custom exception: org.apache.commons.jxpath.JXPathException: Cannot create a relative context for a non-existent node: /form/test at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getRelativeContext(JXPathContextReferenceImpl.java:581) at org.apache.cocoon.forms.binding.CustomJXPathBinding.doSave(CustomJXPathBinding.java:83) at org.apache.cocoon.forms.binding.JXPathBindingBase.saveFormToModel(JXPathBindingBase.java:192) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1735) Update Jtidy
Update Jtidy Key: COCOON-1735 URL: http://issues.apache.org/jira/browse/COCOON-1735 Project: Cocoon Type: Bug Components: Blocks: HTML Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assigned to: Jean-Baptiste Quenot FYI we had to update jtidy in our project to see an HTML parsing bug fixed. We used this: http://jtidy.sourceforge.net/nightly/jtidy-r8-SNAPSHOT.zip This version was last updated in september 2004. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1711) [PATCH] correct position of help popup for tab styling
[
http://issues.apache.org/jira/browse/COCOON-1711?page=comments#action_12363105
]
Werner Masik commented on COCOON-1711:
--
Sure. Give me 1 or 2 days.
[PATCH] correct position of help popup for tab styling
--
Key: COCOON-1711
URL: http://issues.apache.org/jira/browse/COCOON-1711
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.9-dev (current SVN)
Reporter: Werner Masik
Priority: Minor
Attachments: forms-advanced-field-styling.xsl.diff
Help popups appear in the wrong position when the tab styling is used.
Usually it pops up below the div that contains the tabbed form, which means
that the popup is often outside of the visible viewing area.
Looks like the bug exists since the stylesheets of 2.1.7 and dev branch were
merged.
The problem is that the function forms_createPopupWindow does not get called
when
the page is loaded into the browser. In current 2.1.X branch the function
gets called
directly from the a href= ...
a
onclick=forms_createPopupWindow('email:help').showPopup('email:help:a');return
false; href=# name=email:help:a id=email:help:aimg alt=helppopup
src=resources/forms/img/help.gif/a
So the function is executed when then link to the popup is clicked.
In 2.1.7 it was called like this:
script type=text/javascript
var helpWinN1003B = forms_createPopupWindow('helpN1003B');
/script
a onclick=helpWinN1003B.showPopup('N1003B');return false; href=#
name=N1003B id=N1003Bimg alt=helppopup src=/images/help.gif/a
Here the popup window was created at the first display of the browser page.
Actually when in tab-styling the whole popup-tree was just copied right below
the body-tag because of the positioning issues. This was done
with the forms_moveInBody function which was called in the onload handler of
the forms.
Therefore 2 possible solutions exist:
- revert the code to the old version, to register the handler before the
onload is executed
- alter forms-advanced-field-styling.xsl so the divs for the popups are all
created as a child of the body tag
The patch I'm submitting takes the second aproach. All it does is create the
divs where they should be
from the beginning (below body). This is done by introducing a mode called
'forms-help', to make the fi:help
tags get processed twice. In the first run the divs are created and in the
second run links for the popups
are created just behind the field (as usual). Moving the divs with
javascript therefore becomes obsolete. I think
that registering the onloadHanlder to call forms_moveInBody can be removed.
But I was not sure if
it is needed for something else, so I kept it.
I'm not a XSLT expert. There might be a better way to process the help
popups. Feel free
to make corrections. I also have no experience with ajax. I tested it with
ajax activated
and it worked. But I'm not sure if my test was using ajax the right way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1708) Allow CopletInstanceDataManager to be cloneable
[ http://issues.apache.org/jira/browse/COCOON-1708?page=all ] Jean-Baptiste Quenot closed COCOON-1708: Resolution: Won't Fix Dependant issue COCOON-1709 was closed Allow CopletInstanceDataManager to be cloneable --- Key: COCOON-1708 URL: http://issues.apache.org/jira/browse/COCOON-1708 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Priority: Minor Attachments: 20051212-portal-AbstractAspectalizable, 20051212-portal-CopletInstanceDataManager CopletInstanceDataManager should be cloneable in order to load the coplets one time, and clone that object to provide a different copy for every user (using eg AuthenticationProfileManager). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1648) I18nTransformer add support for ISO8601
[ http://issues.apache.org/jira/browse/COCOON-1648?page=all ] Jean-Baptiste Quenot reassigned COCOON-1648: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) I18nTransformer add support for ISO8601 --- Key: COCOON-1648 URL: http://issues.apache.org/jira/browse/COCOON-1648 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: cocoon-i18n-patch, w3c-date.tar.gz, w3c-date.tar.gz See http://www.w3.org/TR/NOTE-datetime for details about ISO 8601 The main idea of ISO 8601 is to have a variable date format, with variable granularity. Currently I18nTransformer only supports date formats with a fixed pattern. I propose to add in Cocoon two classes from W3C's Jigsaw. DateFormatUtils from Jakarta Commons cannot be used because only the formatting part is implemented. See http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/time/DateFormatUtils.html A patch against I18nTransformer is also provided: when encountering i18n:date src-pattern=iso8601 the special date parser is invoked. Actually this patch only provides the parsing part, not the ISO 8601 formatting part. Because I18nTransformer is intended for presenting a view to the end-user, it is rarely needed to present an ISO-8601-formatted date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1629) No default value in forms binding
[ http://issues.apache.org/jira/browse/COCOON-1629?page=all ]
Jean-Baptiste Quenot reassigned COCOON-1629:
Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team)
No default value in forms binding
-
Key: COCOON-1629
URL: http://issues.apache.org/jira/browse/COCOON-1629
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Versions: 2.1.8
Environment: Operating System: other
Platform: Other
Reporter: Jean-Baptiste Quenot
Assignee: Jean-Baptiste Quenot
Priority: Minor
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1549) [PATCH] Batik Rhino support incompatible with Cocoon's
[ http://issues.apache.org/jira/browse/COCOON-1549?page=all ] Jean-Baptiste Quenot reassigned COCOON-1549: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) [PATCH] Batik Rhino support incompatible with Cocoon's -- Key: COCOON-1549 URL: http://issues.apache.org/jira/browse/COCOON-1549 Project: Cocoon Type: Bug Components: Blocks: Batik Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: patch-rhinointerpreter A bug has been filed at Batik, but nobody has replied yet: http://issues.apache.org/bugzilla/show_bug.cgi?id=35233 The need is to use Batik's Rhino support for adding JavaScript to SVG. The problem is that Batik's RhinoInterpreter sets a custom security domain incompatible with Rhino context from Cocoon's FlowScript which doesn't set one. The idea is to remove Batik's Rhino security controller to ensure proper interoperability between Cocoon and Batik. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1629) No default value in forms binding
[
http://issues.apache.org/jira/browse/COCOON-1629?page=comments#action_12363107
]
Jean-Baptiste Quenot commented on COCOON-1629:
--
To be retested with the following change:
Fix COCOON-1687: When saving a cform, remove xml elements if the value of the
widget is null
http://svn.apache.org/viewcvs.cgi?rev=369507view=rev
No default value in forms binding
-
Key: COCOON-1629
URL: http://issues.apache.org/jira/browse/COCOON-1629
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Versions: 2.1.8
Environment: Operating System: other
Platform: Other
Reporter: Jean-Baptiste Quenot
Assignee: Jean-Baptiste Quenot
Priority: Minor
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1684) geronimo-spec-javamail-*.jar not compliant with JavaMail API
[ http://issues.apache.org/jira/browse/COCOON-1684?page=all ] Jean-Baptiste Quenot reassigned COCOON-1684: Assign To: Jean-Baptiste Quenot geronimo-spec-javamail-*.jar not compliant with JavaMail API Key: COCOON-1684 URL: http://issues.apache.org/jira/browse/COCOON-1684 Project: Cocoon Type: Bug Components: Blocks: Mail Versions: 2.1.8 Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot When geronimo-spec-javamail-*.jar is in WEB-INF/lib along with mail.jar, the former has precedence over the latter. Quoting Upayavira: They are (as far as I understand it) jar files that allow us to compile Cocoon, but do not provide the full functionality that is required and could account for method not yet implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1588) JXPath expressions within jx:forEach are broken
[ http://issues.apache.org/jira/browse/COCOON-1588?page=all ] Jean-Baptiste Quenot reassigned COCOON-1588: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) JXPath expressions within jx:forEach are broken - Key: COCOON-1588 URL: http://issues.apache.org/jira/browse/COCOON-1588 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: jxpathtest.tgz, jxpathtest.tgz JXPath expressions within ft:repeater-widget of a CForms template using jx-macros.xml are evaluated to the empty string. A workaround is to use jx:set to remember the objects contained in flow attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1588) JXPath expressions within jx:forEach are broken
[ http://issues.apache.org/jira/browse/COCOON-1588?page=comments#action_12363108 ] Jean-Baptiste Quenot commented on COCOON-1588: -- To be retested with the template block soon to be imported into branch 2.1 JXPath expressions within jx:forEach are broken - Key: COCOON-1588 URL: http://issues.apache.org/jira/browse/COCOON-1588 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Attachments: jxpathtest.tgz, jxpathtest.tgz JXPath expressions within ft:repeater-widget of a CForms template using jx-macros.xml are evaluated to the empty string. A workaround is to use jx:set to remember the objects contained in flow attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1642) Calling SitemapSource.getInputStream() twice
[ http://issues.apache.org/jira/browse/COCOON-1642?page=all ] Jean-Baptiste Quenot reassigned COCOON-1642: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) Calling SitemapSource.getInputStream() twice Key: COCOON-1642 URL: http://issues.apache.org/jira/browse/COCOON-1642 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Jean-Baptiste Quenot Assignee: Jean-Baptiste Quenot Priority: Critical Attachments: sitemapsource.tar.gz Hello, It seems that Cocoon is broken WRT calling SitemapSource.getInputStream() twice. The first invocation is okay, but the second one is doing a refresh(). Then the environment's context is reset, which is making the request fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1579) Continuation, sendPage and Rhino 1.6r1
[ http://issues.apache.org/jira/browse/COCOON-1579?page=all ] Jean-Baptiste Quenot reassigned COCOON-1579: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) Continuation, sendPage and Rhino 1.6r1 -- Key: COCOON-1579 URL: http://issues.apache.org/jira/browse/COCOON-1579 Project: Cocoon Type: Bug Components: - Flowscript Versions: 2.1.8 Environment: Operating System: Linux Platform: PC Reporter: Philippe Gassmann Assignee: Jean-Baptiste Quenot Attachments: bug.tar I use Rhino 1.6r1 (from trunk svn) in my cocoon. I get a NullPointerException in that case : I first call a flow function to display a jx template using a continuation. Then I post the form (and the continuation) to a pipeline calling a flow function that does a cocoon.sendPage to a pipeline calling the continuation. Then, I does some things in the flow and I display the jx template again. The first time I post the form : OK it's working. The second time I post the form : A NullPointerException is thrown ! Here is the full java stacktrace : java.lang.NullPointerException at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsGet_continuation(FOM_Cocoon.java:252) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:174) at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1617) at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1263) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1332) at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1321) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2744) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2164) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:140) at org.mozilla.javascript.Context.call(Context.java:497) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1496) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1466) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(FOM_JavaScriptInterpreter.java:861) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(SelectNode.java:102) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.handleCocoonRedirect(ConcreteTreeProcessor.java:298) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.access$000(ConcreteTreeProcessor.java:47) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector.cocoonRedirect(ConcreteTreeProcessor.java:339) at org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:59) at org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:209) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.forwardTo(FOM_JavaScriptInterpreter.java:914) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.forwardTo(FOM_Cocoon.java:698) at org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.jsFunction_sendPage(FOM_Cocoon.java:269) at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown
[jira] Assigned: (COCOON-1560) No controls in some case in the sitemap
[ http://issues.apache.org/jira/browse/COCOON-1560?page=all ] Jean-Baptiste Quenot reassigned COCOON-1560: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) No controls in some case in the sitemap --- Key: COCOON-1560 URL: http://issues.apache.org/jira/browse/COCOON-1560 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assignee: Jean-Baptiste Quenot it is possible to type map:paramater name=xxx value=zzz/ in the sitemap without having an error. It occurs when trying to pass some parameters to a flow function, I don't know if its a general issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1698) [PATCH] caching-global-use-attributes does not work
[ http://issues.apache.org/jira/browse/COCOON-1698?page=all ] Jean-Baptiste Quenot reassigned COCOON-1698: Assign To: Carsten Ziegeler (was: Jean-Baptiste Quenot) Please Carsten, could you apply this patch? I think you're the right person to deal with CachingURICoplet. Thanks in advance. [PATCH] caching-global-use-attributes does not work --- Key: COCOON-1698 URL: http://issues.apache.org/jira/browse/COCOON-1698 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Guillaume Déflache Assignee: Carsten Ziegeler Attachments: CachingURICopletAdapter.java.diff Global cache using attributes does not work: an event on a coplet instance always delete the corresponding cache entry. In fact a coplet instance event only allows to modify the coplet instance attributes. However all the attributes are part of the cache key. So modify them must make no cache entry invalid but must lead to the creation of a new entry. Included patch fixes just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1704) Error Message brokenness when SAXON is used as the XSLT transformer.
[ http://issues.apache.org/jira/browse/COCOON-1704?page=all ] Jean-Baptiste Quenot reassigned COCOON-1704: Assign To: Jean-Baptiste Quenot Error Message brokenness when SAXON is used as the XSLT transformer. Key: COCOON-1704 URL: http://issues.apache.org/jira/browse/COCOON-1704 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Pier Fumagalli Assignee: Jean-Baptiste Quenot Attachments: patch.txt SAXON 8.x always fails with a message Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor no matter what error it encounters. This is because it emits this as a warning to its configured ErrorHandler, and o.a.c.c.xslt.TraxErrorListener is configured to handler XALAN's brokenness, and caches warnings. Also, the o.a.c.c.xslt.TraxProcessor class does not allow to set generic attributes in the wrapped SAXTransformerFactory class, so, this can't be solved with configurations. And the only way I found to have SAXON to ignore those warnings is by setting the http://saxon.sf.net/feature/version-warning; attribute to false. This simple patch makes this behavior mandatory when using SAXON, so that error messages work back again no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1705) LDAPTransformer fails with NPE on attribute change - work fine on 2.1.5.1
[ http://issues.apache.org/jira/browse/COCOON-1705?page=all ] Jean-Baptiste Quenot reassigned COCOON-1705: Assign To: Jean-Baptiste Quenot LDAPTransformer fails with NPE on attribute change - work fine on 2.1.5.1 - Key: COCOON-1705 URL: http://issues.apache.org/jira/browse/COCOON-1705 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8 Reporter: Warrell Harries Assignee: Jean-Baptiste Quenot Attachments: 20060117-cocoon-ldaptr-exec_element The following works OK on 2.1.5.1 :- ?xml version=1.0 encoding=ISO-8859-1? ldapuser xmlns:ldap=http://apache.org/cocoon/LDAP/1.0; ldap:execute-replace ldap:initializercom.sun.jndi.ldap.LdapCtxFactory/ldap:initializer ldap:version3/ldap:version ldap:serverurlldap://ldap.westsussex.gov.uk/ldap:serverurl ldap:searchbaseou=training,ou=IRT,ou=apps,o=wscc,dc=westsussex,dc=gov,dc=uk/ldap:searchbase ldap:rootdncn=root/ldap:rootdn ldap:passwordpassw0rd/ldap:password ldap:count-limit0/ldap:count-limit ldap:time-limit0/ldap:time-limit ldap:filter(amp;(uid=irttraining02))/ldap:filter ldap:attribute name=givennametwo/ldap:attribute /ldap:execute-replace /ldapuser but fails with NPE on 2.1.8 java.lang.NullPointerException at org.apache.cocoon.transformation.LDAPTransformer$LDAPQuery.execute(LDAPTransformer.java:1264) at org.apache.cocoon.transformation.LDAPTransformer.executeQuery(LDAPTransformer.java:249) at org.apache.cocoon.transformation.LDAPTransformer.endExecuteElement(LDAPTransformer.java:288) at org.apache.cocoon.transformation.LDAPTransformer.endElement(LDAPTransformer.java:781) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:315) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:334) at org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:325) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:115) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:578) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:480) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:142) at
[jira] Assigned: (COCOON-1686) [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace.
[ http://issues.apache.org/jira/browse/COCOON-1686?page=all ] Jean-Baptiste Quenot reassigned COCOON-1686: Assign To: Jean-Baptiste Quenot [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace. -- Key: COCOON-1686 URL: http://issues.apache.org/jira/browse/COCOON-1686 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Michael Schlotfeldt Assignee: Jean-Baptiste Quenot Attachments: DomHelper.txt, JXPathBindingManager.txt This is a patch to solve bug entry COCOON-1671. The problem was the SAX parser used in createBinding(Source) of JXPathBindingManager did not have the http://xml.org/sax/features/namespace-prefixes; set to true. This ment the namespaces could not be extracted from the DOM when calling getInheritedNSDeclarations(Element). Therefore the JXPathContext was never having namespaces registered. Enabling the features solves these problems. The patch (which is against the SVN as of today) that are being submit changes 2 files: (1) DomHelper.java (2)JXPathBindingMangager In DomHelper I added an additional parse method that takes a SAXParser in place of the servicemanager. This way you can set features on the SAXParser before the parsing to dom is done. The parse method that existed before still does but i modified that as well so it uses the new method so we do not duplicate code. Three more things: 1. My experinece with Excalibur is not complete. I am unsure if i can lookup the SAXParser and then parametize it. Or if it should be done another way. The patch looks it up and then parametizes this. I believe this is the correct way, but if it is not please let me know. 2. The SAXParser used by JXPathBindingMangager no turns on the feature we want. But the JaxpParser class from Excalibur (which is what is returned) has a system print out in it if you enable the feature we are now. So everytime a binding occurs it says: NAMESPACE PREFIX!!. If anybody has acces to the repository for that class PLEASE remove that line. It shoudl not be there. 3. There is another bug report for the form samples (#6) that uses namespace binding. I need somebody to confirm this but it appears that this patch also fixes that bug report. The number for that report is: COCOON-1595 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Assigned: (COCOON-1698) [PATCH] caching-global-use-attributes does not work
Jean-Baptiste, please don't assign other people to issues. With assigning someone you create an expectation that might not be met from the person you assign. So please change this back. I might have a look at this issue *when* I have time to do so. In the meantime, perhaps someone else, will look at it. Thanks Carsten Jean-Baptiste Quenot (JIRA) schrieb: [ http://issues.apache.org/jira/browse/COCOON-1698?page=all ] Jean-Baptiste Quenot reassigned COCOON-1698: Assign To: Carsten Ziegeler (was: Jean-Baptiste Quenot) Please Carsten, could you apply this patch? I think you're the right person to deal with CachingURICoplet. Thanks in advance. [PATCH] caching-global-use-attributes does not work --- Key: COCOON-1698 URL: http://issues.apache.org/jira/browse/COCOON-1698 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Guillaume Déflache Assignee: Carsten Ziegeler Attachments: CachingURICopletAdapter.java.diff Global cache using attributes does not work: an event on a coplet instance always delete the corresponding cache entry. In fact a coplet instance event only allows to modify the coplet instance attributes. However all the attributes are part of the cache key. So modify them must make no cache entry invalid but must lead to the creation of a new entry. Included patch fixes just this. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Assigned: (COCOON-1489) [PATCH] XInclude transformer does not handle fallback correctly
[ http://issues.apache.org/jira/browse/COCOON-1489?page=all ] Jean-Baptiste Quenot reassigned COCOON-1489: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) [PATCH] XInclude transformer does not handle fallback correctly --- Key: COCOON-1489 URL: http://issues.apache.org/jira/browse/COCOON-1489 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Joachim Breitsprecher Assignee: Jean-Baptiste Quenot Attachments: cocoon-xinclude-transformer-patch.txt When using the xi:fallback element, the XInclude transformer returns a not-well-formed document. Example: root xmlns:xi=http://www.w3.org/2001/XInclude; xi:include href=this_file_does_not_exist.xml xi:fallback elementThis should be here if the file was not found/element /xi:fallback /xi:include /root returns this, if the included resource does not exist: ?xml version=1.0 encoding=ISO-8859-1?root xmlns:xi=http://www.w3.org/2001/XInclude; elementThis should be here if the file was not found /xi:include /root -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1603) [PATCH] handling of alternatives in MailTransformer
[ http://issues.apache.org/jira/browse/COCOON-1603?page=all ] Jean-Baptiste Quenot reassigned COCOON-1603: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) [PATCH] handling of alternatives in MailTransformer --- Key: COCOON-1603 URL: http://issues.apache.org/jira/browse/COCOON-1603 Project: Cocoon Type: Improvement Components: Blocks: Mail Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Ãric BURGHARD Assignee: Jean-Baptiste Quenot Priority: Minor Attachments: SendMailTransformer.java.patch Enable alternative format for the same content in MailTransformer. For example you can write email:sendmail email:body mime-type=text/plain Hello World /email:body email:body mime-type=text/html html body h1Hello World/h1 /body /html /email:body /email:sendmail to enable a multipart/alternative sending. internaly, a body is just an attachment without name and without xml header. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1671) Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace.
[ http://issues.apache.org/jira/browse/COCOON-1671?page=all ] Jean-Baptiste Quenot reassigned COCOON-1671: Assign To: Jean-Baptiste Quenot (was: Cocoon Developers Team) Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace. -- Key: COCOON-1671 URL: http://issues.apache.org/jira/browse/COCOON-1671 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Suzan Foster Assignee: Jean-Baptiste Quenot Attachments: JXPathTest.java, form2_bind_xml1.xml, form2_bind_xml2.xml, form2_bind_xml3.xml, form2_data.xml In the situation where the binding definition and the instance data share the same namespace uri but have different namespace prefixes the binding will fail. However, when the binding definition and the instance data share the same namespace prefix but not the same namespace uri the binding will be successful. This is incorrect as it shound match on the namespace uri's and not on the prefixes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1698) [PATCH] caching-global-use-attributes does not work
[ http://issues.apache.org/jira/browse/COCOON-1698?page=all ] Jean-Baptiste Quenot reassigned COCOON-1698: Assign To: (was: Carsten Ziegeler) No problem, please assign yourself this issue if you feel concerned, thanks [PATCH] caching-global-use-attributes does not work --- Key: COCOON-1698 URL: http://issues.apache.org/jira/browse/COCOON-1698 Project: Cocoon Type: Bug Components: Blocks: Portal Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Guillaume Déflache Attachments: CachingURICopletAdapter.java.diff Global cache using attributes does not work: an event on a coplet instance always delete the corresponding cache entry. In fact a coplet instance event only allows to modify the coplet instance attributes. However all the attributes are part of the cache key. So modify them must make no cache entry invalid but must lead to the creation of a new entry. Included patch fixes just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1734) Forms library not honouring cross-referencing classes
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ] Jean-Baptiste Quenot reassigned COCOON-1734: Assign To: (was: Max Pfingsthorn) Please assign yourself this issue if you feel concerned, thanks Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: NPE in AbstractWidgetDefinition when using library
* Daniele Madama: I'm using forms library from svn updated some minutes ago, if I extend a field from library I got a NPE at row 92 of AbstractWidgetDefinition because the property attributes is null, probably this map was never initialized. Can you attach a stacktrace, or better file a JIRA issue? Thanks in advance, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: how can I build trunk?
* Carsten Ziegeler: Or we can exclude them as we don't need the d-haven implementation. With ECM++ we use our own stuff. I tried to remove the dependency, and got many such errors: cocoon-trunk/cocoon-databases/src/main/java/org/apache/cocoon/acting/DatabaseSelectAction.java:[56,8] cannot resolve symbol symbol : class DataSourceComponent location: class org.apache.cocoon.acting.DatabaseSelectAction Can you explain what is needed to satisfy this dependency? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: how can I build trunk?
Jean-Baptiste Quenot schrieb: * Carsten Ziegeler: Or we can exclude them as we don't need the d-haven implementation. With ECM++ we use our own stuff. I tried to remove the dependency, and got many such errors: cocoon-trunk/cocoon-databases/src/main/java/org/apache/cocoon/acting/DatabaseSelectAction.java:[56,8] cannot resolve symbol symbol : class DataSourceComponent location: class org.apache.cocoon.acting.DatabaseSelectAction Can you explain what is needed to satisfy this dependency? I assume that you exclude the excalibur-datasource dependency? You have to leave that one in, but define excludes for the transitive dependencies as some excalibur stuff depends on the d-haven stuff. You can have a look at the pom in the core module which has some examples. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: New skin for web site
Ross Gardler wrote: 2) are there any web designers here willing to work on the skin (you don't need to learn how to get it into Forrest at first, just provide CSS patches and I'll integrate with Forrest for you - you'll quickly see how it is done) I'm not a graphics designer (i.e. my Photoshop skills are very limited), but I have a good knowledge of CSS and many of the various browser peculiarities. I'd love to get my hands on this. If you could provide me the end result (i.e. some HTML pages and the resources like images and CSS), I'll give it a go. Bye, Helma
Re: how can I build trunk?
* Carsten Ziegeler: Jean-Baptiste Quenot schrieb: I tried to remove the dependency, and got many such errors: cocoon-trunk/cocoon-databases/src/main/java/org/apache/cocoon/acting/DatabaseSelectAction.java:[56,8] cannot resolve symbol symbol : class DataSourceComponent location: class org.apache.cocoon.acting.DatabaseSelectAction Can you explain what is needed to satisfy this dependency? I assume that you exclude the excalibur-datasource dependency? You have to leave that one in, but define excludes for the transitive dependencies as some excalibur stuff depends on the d-haven stuff. You can have a look at the pom in the core module which has some examples. Thank you! It works. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: how can I build trunk?
Daniel Fagerstrom wrote: 1. Help moving artifacts that we use from the Apache repository to the much better and mirrored ibiblio repository, see http://maven.apache.org/project-faq.html. just a quick note wrt to this : you'll find that late afternoon CET even ibiblio will often time out. This is a known issue, last i heard is that they are looking to move the central repo somewhere else. Best bet is to allways specify the european mirror in settings.xml (if you're living in europe ofcourse) and run maven -s settings.xml ... . The maven docs have a list of all the repos somewhere. Jorg
Re: how can I build trunk?
Daniel Fagerstrom wrote: You find instructions in the end of http://cocoon.zones.apache.org/daisy/documentation/g2/756.html. Now I'm a little bit suprized that it is missing, IIRC, that jar is used in the Excalibur project, and Jorg worked together with Excalibur to move Excalibur to M2. Hopefully Jorg can comment. I see Carsten provided the solution already, great ! (Excalibur should really decide on their next release so we can push all the artifacts from cvs.a.o to the central repo) Jorg (who just started a new contract and will only sporadically be able to catch up on dev@ mail)
Success stories
Sorry to be here in this mailing list. I just wanted to point out that there's no easy way to find a list of Cocoon success stories. We are evaluating Cocoon for a banking application as a foundation to build our own customized form generation system. It would help a lot if I could show where Cocoon is being used (big names preferrred). I suggest you put that information somewhere visible. Other projects already do that (http://subversion.tigris.org/testimonials.html, http://wiki.apache.org/struts/StrutsWebLinks). I know it can soud unfair but enterprises pay attention to who has already used that? when evaluating products. Considere adding such a list. If there's a page I've missed please tell me, I'd need that info! Thanks!
Re: Success stories
Hi Nicolás, there is a section called Live Sites on the Cocoon Website which lists many websites running a certain version of Cocoon: http://cocoon.apache.org/link/livesites-2.1.html http://cocoon.apache.org/link/livesites-2.0.html http://cocoon.apache.org/link/livesites-1.x.html Perhaps you can find there what you are looking for ... HTH, Andreas Nicolás Lichtmaier schrieb: Sorry to be here in this mailing list. I just wanted to point out that there's no easy way to find a list of Cocoon success stories. We are evaluating Cocoon for a banking application as a foundation to build our own customized form generation system. It would help a lot if I could show where Cocoon is being used (big names preferrred). I suggest you put that information somewhere visible. Other projects already do that (http://subversion.tigris.org/testimonials.html, http://wiki.apache.org/struts/StrutsWebLinks). I know it can soud unfair but enterprises pay attention to who has already used that? when evaluating products. Considere adding such a list. If there's a page I've missed please tell me, I'd need that info! Thanks!
Re: Success stories
On 18.01.2006 23:06, Nicolás Lichtmaier wrote: Sorry to be here in this mailing list. I just wanted to point out that there's no easy way to find a list of Cocoon success stories. We are evaluating Cocoon for a banking application as a foundation to build our own customized form generation system. It would help a lot if I could show where Cocoon is being used (big names preferrred). I suggest you put that information somewhere visible. Other projects already do that (http://subversion.tigris.org/testimonials.html, http://wiki.apache.org/struts/StrutsWebLinks). I know it can soud unfair but enterprises pay attention to who has already used that? when evaluating products. Considere adding such a list. If there's a page I've missed please tell me, I'd need that info! Hello Nicolás, yes, there is such a page, at least as pure list of links: http://cocoon.apache.org/link/livesites-2.1.html. With the big names it is somewhat difficult. You have to search them in the list. The big names that I would mention are vnunet.com, the Eurex and Eurex US and the Swiss Exchange. This pure list was extended to success stories or with additional information some time ago: http://cocoon.zones.apache.org/daisy/documentation/695.html. But not so many links were added with this additional information up to now. Hope this helps. Jörg
Re: Success stories
yes, there is such a page, at least as pure list of links: http:// cocoon.apache.org/link/livesites-2.1.html. With the big names it is somewhat difficult. You have to search them in the list. The big names that I would mention are vnunet.com, the Eurex and Eurex US and the Swiss Exchange. There is also Dresdner Bank and Vodafone ...and I know O2 is using it ...and there are a few more banks. Not sure about there official statements though. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: Success stories
On 18.01.2006 23:06, Nicolás Lichtmaier wrote: Sorry to be here in this mailing list. I just wanted to point out that there's no easy way to find a list of Cocoon success stories. We are evaluating Cocoon for a banking application as a foundation to build our own customized form generation system. It would help a lot if I could show where Cocoon is being used (big names preferrred). Another interesting list might be http://codeconsult.ch/bertrand/archives/000389.html. We had a success stories session at the Cocoon GetTogether 2004. That's what Bertrand's post is about. The minutes of the session can be found at http://wiki.apache.org/cocoon/GT2004Gianugo. Jörg
Re: Success stories
On 18.01.2006 23:51, Torsten Curdt wrote: There is also Dresdner Bank and Vodafone ...and I know O2 is using it ...and there are a few more banks. Not sure about there official statements though. We can at least provide official hints: http://marc.theaimsgroup.com/?l=xml-cocoon-usersw=4r=1s=Jonas+Kilianq=b :) Jörg
[EMAIL PROTECTED]: Project packaged-jmock (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project packaged-jmock has an issue affecting its community integration. This issue affects 147 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - authx-core : Apache Authentication and Authorization Framework - authx-example : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-jelly-tags-ojb : Commons Jelly - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable components. - excalibur-cornerstone-sockets-impl : Repository of reusable components. - excalibur-cornerstone-store-impl : Repository of reusable components. - excalibur-cornerstone-threads-api : Repository of reusable components. - excalibur-cornerstone-threads-impl : Repository of reusable components. - excalibur-datasource : Repository of reusable components. - excalibur-event : Repository of reusable components. - excalibur-event-impl : Repository of reusable components. - excalibur-fortress-bean : Repository of reusable components. -
[EMAIL PROTECTED]: Project packaged-jmock (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project packaged-jmock has an issue affecting its community integration. This issue affects 147 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - authx-core : Apache Authentication and Authorization Framework - authx-example : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-faces : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slide : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-webdav : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - commons-jelly-tags-ojb : Commons Jelly - db-ojb : ObjectRelationalBridge - db-ojb-from-packages : ObjectRelationalBridge - db-torque : Persistence Layer - excalibur-component : Repository of reusable components. - excalibur-cornerstone-connection-api : Repository of reusable components. - excalibur-cornerstone-connection-impl : Repository of reusable components. - excalibur-cornerstone-datasources-impl : Repository of reusable components. - excalibur-cornerstone-scheduler-impl : Repository of reusable components. - excalibur-cornerstone-sockets-impl : Repository of reusable components. - excalibur-cornerstone-store-impl : Repository of reusable components. - excalibur-cornerstone-threads-api : Repository of reusable components. - excalibur-cornerstone-threads-impl : Repository of reusable components. - excalibur-datasource : Repository of reusable components. - excalibur-event : Repository of reusable components. - excalibur-event-impl : Repository of reusable components. - excalibur-fortress-bean : Repository of reusable components. -
[EMAIL PROTECTED]: Project jing (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jing has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - jing : Jing performs XML Validation using RelaxNG schemas Full details are available at: http://vmgump.apache.org/gump/public/cocoon/jing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jing-20030619.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/tools/lib/jing-20030619.jar -ERROR- No such directory (where output is expected) : /usr/local/gump/public/workspace/cocoon/tools/lib -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/jing/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/jing/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 14001618012006, vmgump.apache.org:vmgump-public:14001618012006 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[EMAIL PROTECTED]: Project jing (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project jing has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Missing Build Outputs'. For reference only, the following projects are affected by this: - jing : Jing performs XML Validation using RelaxNG schemas Full details are available at: http://vmgump.apache.org/gump/public/cocoon/jing/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jing-20030619.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/tools/lib/jing-20030619.jar -ERROR- No such directory (where output is expected) : /usr/local/gump/public/workspace/cocoon/tools/lib -DEBUG- Extracted fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/jing/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/jing/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 14001618012006, vmgump.apache.org:vmgump-public:14001618012006 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
Re: Success stories
Hi Nicolás, Glad to see you considering Cocoon. I think it is a good choice. Unfortunately, I tried to find the Gianugo presentation online but seems like there is not. Maybe Gianugo can share with us the presentation in http://cocoon.apache.org/mirror.cgi under Material form events presentations. Gianugo? :-) Best Regards, Antonio Gallardo Nicolás Lichtmaier wrote: Sorry to be here in this mailing list. I just wanted to point out that there's no easy way to find a list of Cocoon success stories. We are evaluating Cocoon for a banking application as a foundation to build our own customized form generation system. It would help a lot if I could show where Cocoon is being used (big names preferrred). I suggest you put that information somewhere visible. Other projects already do that (http://subversion.tigris.org/testimonials.html, http://wiki.apache.org/struts/StrutsWebLinks). I know it can soud unfair but enterprises pay attention to who has already used that? when evaluating products. Considere adding such a list. If there's a page I've missed please tell me, I'd need that info! Thanks!
Re: Cocoon 2.1.7 hang
I thought I'd update you all on the problems we have been having with our production deployment. We finally rolled out an update that include proper pool sizes for the components and the fix to the Castor mapping file. However, before we did that our system engineer provided some valuable insight. He provided a graph that shows one CPU going into a hard loop. About 7 minutes later the system became completely congested and ran out of threads. The pool and mapping file changes helped in that when the first failure after the changes occured it took about 30 minutes for the system to run out of threads. However, that information caused me to go back and look at my stack traces. It turns out that everyone single one (with the exception noted below) showed one thread doing the same thing. Now, we first deployed this product in March of 2005 and experienced no failures until a product update was released in August. That update included some new calculators written in flowscript. This version of Cocoon is using rhino1.5r4-continuations-20040629T1232.jar. The stack traces indicate that these are going into a loop and causing the system to die. At first we thought that the calculators were not doing proper input validation and causing the wierd things to happen. The stack traces kind of supported this in that they look like: http-8080-Processor18 daemon prio=1 tid=0x30e38df8 nid=0x51a8 runnable [2d351000..2d35387c] at java.lang.Class.isPrimitive(Native Method) at org.mozilla.javascript.NativeJavaObject.getConversionWeight(NativeJavaObject.java:324) at org.mozilla.javascript.NativeJavaObject.canConvert(NativeJavaObject.java:259) at org.mozilla.javascript.NativeJavaMethod.findFunction(NativeJavaMethod.java:356) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:193) at org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1134) 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.handleContinuation(FOM_JavaScriptInterpreter.java:812) - locked 0x66005778 (a org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter$ThreadScope) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) However, we have been able to recreate the loop without entering bad data. In addition, we got a trace that was close to the start of the loop and it is somewhat different. It seems to imply that there is something wrong with Continuation handling, but I have no idea. Two traces taken a few minutes later both looked like the one above. at org.mozilla.javascript.Interpreter.doubleWrap(Interpreter.java:2491) at org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:657) 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.handleContinuation(FOM_JavaScriptInterpreter.java:812) - locked 0x66005880 (a org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter$ThreadScope) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:123) We have a way to get around this problem by replacing the flowscript calculators with CGIs for the time being. However, we will want to do something about this problem in the future. One difficulty in debugging this problem though is that we have no idea which calculators are running or where they are at the time of the failure because interpreted javascript doesn't show up in the stack trace. As a consequence I will probably recommend that they be rewritten as JSR-168 portlets instead of using flow - unless someone has a better idea. Thoughts and comments are welcome. Ralph
Re: Cocoon 2.1.7 hang
On 1/18/06, Ralph Goers [EMAIL PROTECTED] wrote: However, we have been able to recreate the loop without entering bad data. How ? Just random pounding on the calculator? Thoughts and comments are welcome. Looks to me like both times you've caught the process of a continuation being trapped and a flow script being executed as a result. Slightly different exit out of the continuations handler however: ContinuationInterpreter.interpret(ContinuationInterpreter.java:657) may provide the clue you need? Break points on one of the earlier ContinuationInterpreter points might also help if you can reproduce with a debugger attached? -- Peter Hunsberger
[Help]How can I just build trunk easily
Hi,cocooners: I got trunk from svn,I download maven,but when I run mvn ,it always need to download something and can never complete it successfully(my network condition is not so good).I just want to build trunk just like 2.1,how can I do that? Another problem ,I can't update branch_2_1_x from svn these few days,always said src/block/ajax already exits(something like that) Roy Huang
Re: cforms demo for 2.1.9-dev broken....
Antonio Gallardo wrote: Hi folks, the subject says all [1] Best Regards, Antonio Gallardo. [1] http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/ Sorry for the noise, more testing drives me to see there is not only the forms block, there are other links broken, for example: http://cocoon.zones.apache.org/logs/cocoon-demos -- /Connection reset by peer http://cocoon.zones.apache.org/daisy/ --// Connection reset by peer/ / Is this only my conection or anybody else can see the problem? Best Regards, Antonio Gallardo /
Re: Cocoon 2.1.7 hang
Peter Hunsberger wrote: On 1/18/06, Ralph Goers [EMAIL PROTECTED] wrote: However, we have been able to recreate the loop without entering bad data. How ? Just random pounding on the calculator? Yup. With nornal input. Thoughts and comments are welcome. Looks to me like both times you've caught the process of a continuation being trapped and a flow script being executed as a result. Slightly different exit out of the continuations handler however: ContinuationInterpreter.interpret(ContinuationInterpreter.java:657) may provide the clue you need? Break points on one of the earlier ContinuationInterpreter points might also help if you can reproduce with a debugger attached? I looked at what I believe is the right version of ContinuationInterpreter (http://svn.cocoondev.org/repos/rhino+cont/branches/BEFORE_PACKAGENAME_CHANGE/rhino1_5R4pre/src/org/mozilla/javascript/continuations/ContinuationInterpreter.java) and found that it has a while(true) look and that both line 657 and line 1134 are within it. The loop has a really large switch statement (line 657 is TokenStream.SETNAME and 1134 is NON_TAIL_CALL . Unfortunately, I have no idea what it is trying to do. but apparently it never breaks out of the loop. Ralph
Re: cforms demo for 2.1.9-dev broken....
From: Antonio Gallardo [EMAIL PROTECTED] Date: Thu, 19 Jan 2006 00:27:44 -0600 Antonio Gallardo wrote: [snip] http://cocoon.zones.apache.org/logs/cocoon-demos -- /Connection reset by peer http://cocoon.zones.apache.org/daisy/ --// Connection reset by peer/ / Is this only my conection or anybody else can see the problem? It's not just you. I don't see Connection reset by peer, though, I get a 500 page instead. HTML !-- $Id: //depot/prod/ontap/Rbrutus/prod/netcache/errors/500.html#1 $ -- HEADTITLE500 Server Error/TITLE/HEAD BODY H1Server Error/H1 H4 The following error occurred:P [code=CANT_CONNECT] Could not connect because of networking problems. Contact your system administrator. /H4 HR Please contact the administrator. /BODY /HTML Andrew.
