Re: [RT] Rules for adding blocks and functionality?
Le 24 oct. 05, à 06:50, Niclas Hedhman a écrit : I would like to propose; 1. Make Apache Cocoon 3.0 into the slim down, no frills, no blocks, no nothing, thing that has been discussed recently... Agreed, and even start this with 2.2, IIUC as soon as mavenizaion is finished, blocks can start living their own life. 2. Create subprojects in Apache Cocoon for heavily used blocks, which every user can't live without. Since blocks are bundles, something like the Oscar Bundle Repository would make it a piece of cake for users to install them... Even without OSGI, moving (physically or otherwise) all blocks which do not have strong community support to a contrib directory as suggested before would help a lot already. People who rely on those blocks will then have to find a way to have them supported, but it would allow us to focus on a primary mission of delivering a consistent, tested and well-documented core. 3. Create a user friendly block exchange elsewhere (cocoon-dev), where developers can publish and categorize their creations even if they are not Cocoon committers. A kind of Wiki brought to Coding, which I find useful. The 'deprecated' stuff is moved here, for the sake of availability, and allowance to fix bugs et cetera. Rhymes well with Daniel's assertion that it becomes the user's reponsibility to maintain. As well as, Don't kill old stuff. and Respect the past expressed by others... Sounds good, and as a first step this could be our own contrib directory. -Bertrand
Re: [RT] Rules for adding blocks and functionality?
Le 23 oct. 05, à 21:48, Andrew Savory a écrit : ...On 23 Oct 2005, at 19:20, Daniel Fagerstrom wrote: Just because of its importance, you agree that it is important don't you ;) we should follow our usual and well proven development patterns which involves community involvement. FWIW, Sylvain showed quite a few people an example of this functionality at the hackathon, and I think we all said ooh, please commit it ASAP! at the time. So there was some community involvement (though I know there's no substitute for doing it on the list, where the whole community can see)... Agreed, I am one of those people, I even followed Upayavira into hinting about this on the users list (http://marc.theaimsgroup.com/?l=xml-cocoon- usersm=112869263714366w=2) to pressure Sylvain to commit this stuff early ;-) So Andrew you're right, there was community involvement, but not in the usual open-on-the-list way due to the F2F meetings at the GT. We deserve a virtual slap on the fingers for that I guess...but it's for a good cause! I agree with Daniel about the general rules for adding new stuff, but at the same time Sylvain's jdbi sample is exciting enough to have it in the next release IMHO. -Bertrand
RE: Identifier used in FragmentExtractorTransformer
So what is your solution? I can't find it in the mail archive... -Oorspronkelijk bericht- Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 21 oktober 2005 23:14 Aan: dev@cocoon.apache.org Onderwerp: Re: Identifier used in FragmentExtractorTransformer On 21.10.2005 08:54, Bart Molenkamp wrote: How is this problem related to caching? It is not that hard for me to provide a patch which just generates a new identifier, but I'm wondering if it breaks caching... It is related to caching as the cache key is only based on the request uri and the fragment id. So with always the same uri and id you will always get the same content from the cache. Unfortunately nobody ever responded to my proposals about fixing it. Jörg Van: Joerg Heinicke Verzonden: donderdag 20 oktober 2005 20:35 My problem is that the id is based on the request uri (and the number of fragments that it extracts during a single transformation). http://issues.apache.org/bugzilla/show_bug.cgi?id=28724
WTF? Where is the COCOON project in Jira?
I went to bed last night after having migrated almost successfully the Cocoon project from Bugzilla to Jira... Then I woke up today and everything has disappeared from Jira! Who deleted it??? Pier smime.p7s Description: S/MIME cryptographic signature
Re: WTF? Where is the COCOON project in Jira?
On Mon, Oct 24, 2005 at 08:03:43AM +0100, Pier Fumagalli wrote: I went to bed last night after having migrated almost successfully the Cocoon project from Bugzilla to Jira... Then I woke up today and everything has disappeared from Jira! Who deleted it??? Me, sorry - I'm trying to get rid of the extra changeitem records in the db which are preventing the automatic bug key redirection, and importing from scratch looks necessary. It will also get dependencies imported, as well as votes (I just added this to the importer). --Jeff Pier
Re: WTF? Where is the COCOON project in Jira?
On 24 Oct 2005, at 08:16, Jeff Turner wrote: On Mon, Oct 24, 2005 at 08:03:43AM +0100, Pier Fumagalli wrote: I went to bed last night after having migrated almost successfully the Cocoon project from Bugzilla to Jira... Then I woke up today and everything has disappeared from Jira! Who deleted it??? Me, sorry - I'm trying to get rid of the extra changeitem records in the db which are preventing the automatic bug key redirection, and importing from scratch looks necessary. It will also get dependencies imported, as well as votes (I just added this to the importer). Cool... Let me know when you're done and I'll start the new (and hopefully final this time) import! :-) Pier smime.p7s Description: S/MIME cryptographic signature
treeprocessor doesn't resolve variables in all attributes of sitemap nodes
Hi there,
just found out that
map:serialize status-code={statusCode} /
kept giving me a statuscode 200 no matter what the value of statusCode was.
as it turns out the SerializeNodeBuilder will in it's buildNode do:
this.node = new SerializeNode(
type,
VariableResolverFactory.getResolver(config.getAttribute(src,
null), this.manager),
VariableResolverFactory.getResolver(config.getAttribute(mime-type, null),
this.manager),
config.getAttributeAsInteger(status-code, -1)
);
which I read as: @src and @mime-type can but @status-code can-not be
resolved from variables
from an end-user POV this difference in handling is quite arbitrary
(meaning: if there are good considerations for this we should document
them well)
other examples of non-resolvable attributes:
./ActionSetNodeBuilder.java: name
./ActNodeBuilder.java:set
./ActNodeBuilder.java:name
./ActNodeBuilder.java:src
./CallNodeBuilder.java: resource
./CallNodeBuilder.java: function
./CallNodeBuilder.java: continuation
./HandleErrorsNodeBuilder.java: type
./HandleErrorsNodeBuilder.java: when
./FlowNodeBuilder.java: language
./MatchNodeBuilder.java: pattern
./MatchNodeBuilder.java: name
./MountNodeBuilder.java: check-reload
./MountNodeBuilder.java: pass-through
./PipelineNodeBuilder.java: internal-only
./RedirectToNodeBuilder.java: resource
./RedirectToNodeBuilder.java: target
./RedirectToNodeBuilder.java: session
./RedirectToNodeBuilder.java: global
./RedirectToNodeBuilder.java: permanent
./ReadNodeBuilder.java: mime-type
./ReadNodeBuilder.java: status-code
./SerializeNodeBuilder.java: mime-type
./SerializeNodeBuilder.java: status-code
./ScriptNodeBuilder.java:src
./SitemapLanguage.java: logger
./SitemapLanguage.java: role
./SitemapLanguage.java: class
./ViewNodeBuilder.java: from-label
./ViewNodeBuilder.java: from-position
# based on the naieve lookup through
$ cd src/java/org/apache/cocoon/components/treeprocessor/sitemap/;
$ find -type f |xargs grep 'config\.get' | grep -v '\.svn' | grep -v
VariableResolverFactory ~/UnresolvedSitemapAttributes.txt
anyone any opinion on these?
maybe it makes sense to look at these with our rule of least
surprise-glasses on?
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Rules for adding blocks and functionality?
Bertrand Delacretaz wrote: Le 23 oct. 05, à 21:48, Andrew Savory a écrit : ...On 23 Oct 2005, at 19:20, Daniel Fagerstrom wrote: Just because of its importance, you agree that it is important don't you ;) we should follow our usual and well proven development patterns which involves community involvement. FWIW, Sylvain showed quite a few people an example of this functionality at the hackathon, and I think we all said ooh, please commit it ASAP! at the time. So there was some community involvement (though I know there's no substitute for doing it on the list, where the whole community can see)... Agreed, I am one of those people, I even followed Upayavira into hinting about this on the users list (http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=112869263714366w=2) to pressure Sylvain to commit this stuff early ;-) So Andrew you're right, there was community involvement, but not in the usual open-on-the-list way due to the F2F meetings at the GT. We deserve a virtual slap on the fingers for that I guess...but it's for a good cause! And a special virtual slap for me as I concentrated on changes and fixes on CForms rather than committing this sample earlier so that people can look at it. And especially considering that it took me about 2 hours to write it, comments included ;-) Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] Rules for adding blocks and functionality?
Daniel Fagerstrom wrote: We are chosen as committers as induviduals and not as representants for our companies. From a community stand point I would say that it is time to deprecate the SQLTransformer. As a representative for my company I would rather say: no way, we have tons of code that depend on it. It is a complicated question, but I don't think that the answer is: I need it at my work so the rest of you should support it. It is really hard to tell what is still useful and what not. Now, the simple example of the SQLTransformer shows this: most of us seem to agree that it's some legacy component and that flow etc. should be used instead. Now, think of a reporting tool done with Cocoon. This fetches some hundreds of MB out of the database and just displays them. In this case everything other than the SQLTransformer + Stylesheet is simply overkill (ok, XSP+ESQL is fine as well) and too memory/time consuming. With 2.2 we will come to an own release cycle per block, we have defined apis. So we can simply build the 2.2 version of a block, like the databases block, and as this block only uses the well defined public api, it will run for the next years without any changes. And this means no new releases of this block are requried. So the maintenance for this block should be near to zero - Ok, I know that this is the theory and the practice will be slightly different...but anyway, this is one of the aims we target with 2.2. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: forms documentation updates
On Sun, 2005-10-23 at 23:13 +0200, Sylvain Wallez wrote: Bruno Dumon wrote: Hi, you might have seen the notification mails on the docs list for updates to the forms documentation, but is probably easier if I explain what I've done: snip/ Great job Bruno! I started filling some blanks, starting with Ajax and will continue next week also! Cool! Thanks. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Rules for adding blocks and functionality?
Bertrand Delacretaz wrote: Le 24 oct. 05, à 06:50, Niclas Hedhman a écrit : I would like to propose; 1. Make Apache Cocoon 3.0 into the slim down, no frills, no blocks, no nothing, thing that has been discussed recently... Agreed, and even start this with 2.2, IIUC as soon as mavenizaion is finished, blocks can start living their own life. 2. Create subprojects in Apache Cocoon for heavily used blocks, which every user can't live without. Since blocks are bundles, something like the Oscar Bundle Repository would make it a piece of cake for users to install them... Even without OSGI, moving (physically or otherwise) all blocks which do not have strong community support to a contrib directory as suggested before would help a lot already. People who rely on those blocks will then have to find a way to have them supported, but it would allow us to focus on a primary mission of delivering a consistent, tested and well-documented core. 3. Create a user friendly block exchange elsewhere (cocoon-dev), where developers can publish and categorize their creations even if they are not Cocoon committers. A kind of Wiki brought to Coding, which I find useful. The 'deprecated' stuff is moved here, for the sake of availability, and allowance to fix bugs et cetera. Rhymes well with Daniel's assertion that it becomes the user's reponsibility to maintain. As well as, Don't kill old stuff. and Respect the past expressed by others... Sounds good, and as a first step this could be our own contrib directory. No it wouldn't, because we wouldn't agree what should go there. My suggestion is to, as you did with the samples, leave all blocks as they are, and start _hightlighting_ the ones we consider to be best practices. Then, after some extended period if time we may decide to purge the ones that have not received any highlighting, but highlighting core blocks works much better than deprecating old blocks that people may be using. (And by way of recommendation of this approach :-) this is the approach that Buddhists throughout the centuries used to deal with teachings that had grown stale. They didn't say that is a bad teaching, they said, hey, we've got a higher teaching.) So, basically, until we've got blocks functioning, and have had them so for _some_ time, we should do nothing more than highlighting and marking up with meta-data for our blocks. Our blocks system and block repository is going to create a new organism (which, yes, could well want a contrib group elsewhere such as Niclas suggested), but I want to allow for that organism to grow, well, organically :-) Regards, Upayavira
Re: [RT] Rules for adding blocks and functionality?
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: We are chosen as committers as induviduals and not as representants for our companies. From a community stand point I would say that it is time to deprecate the SQLTransformer. As a representative for my company I would rather say: no way, we have tons of code that depend on it. It is a complicated question, but I don't think that the answer is: I need it at my work so the rest of you should support it. It is really hard to tell what is still useful and what not. Now, the simple example of the SQLTransformer shows this: most of us seem to agree that it's some legacy component and that flow etc. should be used instead. Now, think of a reporting tool done with Cocoon. This fetches some hundreds of MB out of the database and just displays them. In this case everything other than the SQLTransformer + Stylesheet is simply overkill (ok, XSP+ESQL is fine as well) and too memory/time consuming. Agree. The really ugly part of SQLTransformer is its ability to perform insert/updates. I'm using ESQL in a number of places for publication purposes, and many people agree that ESQL is what keeps XSP alive. We have to build an equivalent for CTemplates. With 2.2 we will come to an own release cycle per block, we have defined apis. So we can simply build the 2.2 version of a block, like the databases block, and as this block only uses the well defined public api, it will run for the next years without any changes. And this means no new releases of this block are requried. So the maintenance for this block should be near to zero - Ok, I know that this is the theory and the practice will be slightly different...but anyway, this is one of the aims we target with 2.2. And that we more or less currently have. A number of finished blocks (that no more evolve) haven't been touched for ages. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Updated: (COCOON-831) XSLTC doesn't work with nodeset functions
[ http://issues.apache.org/jira/browse/COCOON-831?page=all ] Pier Fumagalli updated COCOON-831: -- Reverting status to NEEDFORINFO as this was not imported from BugZilla. XSLTC doesn't work with nodeset functions - Key: COCOON-831 URL: http://issues.apache.org/jira/browse/COCOON-831 Project: Cocoon Type: Bug Components: sitemap components Versions: 2.1 Environment: Operating System: other Platform: Other Reporter: Peter Broschwitz Assignee: Cocoon Developers Team we are using cocoon 2.1 with xsltc (version 1.4, xalan 2.5.0) as default transformer. Now we want to use the xalan or exslt nodeset function, but this is only possible with xalan xslt. For testing purposes we tried a simple nodeset transformation from the command line. We did that with the same libraries as cocoon, like: $java -Djava.endorsed.dirs=path/to/endorsed/directory org.apache.xalan.xsltc.cmdline.Transform -x node-set-test.xml node_set_test That way, the transformation succeeds. (Compilation before suceeded also, of course.) Trying to process this stylesheet within the cocoon pipeline throws a null pointer exception without any entries in the cocoon-log-files. Changing to xalan-xslt the transformation works without any problems. The stylesheet we used is from the xsltc-documentation: == xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsltc-extension=http://xml.apache.org/xalan/xsltc; xmlns:xalan=http://xml.apache.org/xalan; xmlns:exslt=http://exslt.org/common; version=1.0 xsl:template match=/ xsl:variable name=rtf docelem elem1elem1 gefunden!/elem1 elem2elem2 gefunden!/elem2 /docelem /xsl:variable !-- Use nodeset as an XSLTC extension function -- xsl:value-of select=xsltc-extension:nodeset($rtf)/docelem/elem1/ !-- Use nodeset as a Xalan-Java extension function -- xsl:value-of select=xalan:nodeset($rtf)/docelem/elem1/ !-- Use nodeset as an EXSLT extension function -- xsl:value-of select=exslt:node-set($rtf)/docelem/elem1/ !-- Use nodeset as standard function -- xsl:value-of select=nodeset($rtf)/docelem/elem1/ /xsl:template /xsl:stylesheet == I should add, that none of these nodeset-functions worked, i tested every one of his one and commented out the others. I posted this message already to the cocoon-user-list, and this behaviour could be reproduced by others. Peter -- 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-1175) xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict
[ http://issues.apache.org/jira/browse/COCOON-1175?page=all ] Pier Fumagalli updated COCOON-1175: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. xslt extension functions with bsf broken due to xalan-2.6 / bsf-2.3 conflict Key: COCOON-1175 URL: http://issues.apache.org/jira/browse/COCOON-1175 Project: Cocoon Type: Bug Components: core Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Bruce Robertson Assignee: Cocoon Developers Team xsl comprising extension functions implemented through BSF will throw an error indicating that the required com.ibm.bsf class cannot be found. In fact, the namespace of bsf has changed from com.ibm.bsf to org.apache.bsf in the switch from bsf-2.2.jar, which was in cocoon-2.1.4 and bsf-2.3.jar, which is provided in the bsf block of cocoon-2.1.5 It seems that xalan-2.6, a core component of cocoon-2.1.5, was compiled against the com.ibm.bsf version, and this causes the error. Temporary solution is to add a bsf-2.2.jar file to build/webapp/WEBINF/lib. In the future, perhaps testing should be done for extension functions in xslt. -- 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-740) a crash in the name() function of the xslt, when using SQL transformer
[ http://issues.apache.org/jira/browse/COCOON-740?page=all ]
Pier Fumagalli updated COCOON-740:
--
Reverting status to NEEDFORINFO as this was not imported from BugZilla.
a crash in the name() function of the xslt, when using SQL transformer
--
Key: COCOON-740
URL: http://issues.apache.org/jira/browse/COCOON-740
Project: Cocoon
Type: Bug
Components: sitemap components
Versions: 2.1m2
Environment: Operating System: Linux
Platform: PC
Reporter: Jose de Zarate
Assignee: Cocoon Developers Team
- when using sqltransformer, if on the pipeline the next transformer is
standard
xslt, you can not use name() or local-name() functions for guessing the names
of
the attributes of SQL namespaced elements. (rowset, by example). it throws al
ava.lang.indexOutofBounds exception. It only happens when you use it on
attributes:
xsl:for-each select=@*
xsl:attribute name={name()}blabla/xsl:attribute
/xsl:for-each
but xsl:for-each select=@sql:*
xsl:attrbute name={name()}sdfsdf/xsl:attribute
/xsl:for-each
works fine.
I think it only happes the firts time you enter a sql-namespaced element in
applying the templates.
In cocoon2.0.4 this used to work fine.
the stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 7 = 1
at java.util.Vector.elementAt(Vector.java:427)
at org.apache.xml.dtm.ref.DTMStringPool.indexToString(DTMStringPool.java:137)
at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2.getNodeName(SAX2DTM2.java:2770)
at org.apache.xalan.xsltc.dom.SAXImpl.getNodeName(SAXImpl.java:1016)
at org.apache.xalan.xsltc.dom.DOMAdapter.getNodeName(DOMAdapter.java:282)
at cleanc.applyTemplates()
at cleanc.applyTemplates()
at cleanc.applyTemplates()
at cleanc.transform()
at org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.
java:533)
the stylesheet:
xsl:template match=/
xsl:apply-templates select=block/
/xsl:template
xsl:template match=block
xsl:copy
xsl:for-each select=@*
xsl:attribute name={name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates select=sql:rowset/
/xsl:copy
/xsl:template
xsl:template match=sql:rowset
xsl:copy
xsl:for-each select=@*
xsl:value-of select=local-name()/
/xsl:for-each
/xsl:copy
/xsl:template
this stylesheet is applied after a standard SQLTransformation.
and it crashes on local-name().
--
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-1183) can't use singleton classes in Continuable
[ http://issues.apache.org/jira/browse/COCOON-1183?page=all ]
Pier Fumagalli updated COCOON-1183:
---
Reverting status to NEEDFORINFO as this was not imported from BugZilla.
can't use singleton classes in Continuable
--
Key: COCOON-1183
URL: http://issues.apache.org/jira/browse/COCOON-1183
Project: Cocoon
Type: Bug
Components: blocks
Versions: 2.1.5
Environment: Operating System: Windows XP
Platform: PC
Reporter: Johan Coens
Assignee: Cocoon Developers Team
When using a singleton class in a continuation the error below occurs. I
tried
to save the instance of the singleton class in the context and retrieve it in
the continuable, but the same error occurs. I tried to work with the latest
bcel jar, but this is not compliant with the current javaflow implementation.
I use cocoon 2.1.5 (built from source)
Tomcat 5.0.18
JDK 1.4.2_04
Message: Instruction INVOKEVIRTUAL constraint violated:
Class 'com.mypackage.security.SecurityFactory' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes
of Code attribute '' (method 'public static
com.mypackage.security.SecurityFactory getInstance()') exceeds number of
local
variable slots '0' ('There may be no more than one LocalVariableTable
attribute
per local variable in the Code attribute.'). '. InstructionHandle: 33:
invokevirtual[182](3) 55 Execution Frame: Local Variables: 0:
com.mypackage.cocoon.security.AuthenticationHandler 1: 2: 3: OperandStack:
Slots used: 1 MaxStack: 4. com.mypackage.cocoon.ResourceHelper (Size: 1)
Execution flow: 0: aload_0 [InstructionContext] 1: getfield 22
[InstructionContext] 4: invokevirtual 31 [InstructionContext] 7: ifne - 104
[InstructionContext] 10: aload_0 [InstructionContext] 11: invokevirtual 35
[InstructionContext] 14: ldc 37 [InstructionContext] 16: invokeinterface 43
[InstructionContext] 21: ldc 45 [InstructionContext] 23: invokevirtual 51
[InstructionContext] 26: ifeq - 98 [InstructionContext] 29: aload_0
[InstructionContext] 30: getfield 22 [InstructionContext] 33: invokevirtual
55
[InstructionContext]
Description: org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction INVOKEVIRTUAL constraint violated:
Class 'com.mypackage.security.SecurityFactory' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED Number of LocalVariableTable
attributes
of Code attribute '' (method 'public static
com.mypackage.security.SecurityFactory getInstance()') exceeds number of
local
variable slots '0' ('There may be no more than one LocalVariableTable
attribute
per local variable in the Code attribute.'). '. InstructionHandle: 33:
invokevirtual[182](3) 55 Execution Frame: Local Variables: 0:
com.mypackage.cocoon.security.AuthenticationHandler 1: 2: 3: OperandStack:
Slots used: 1 MaxStack: 4. com.mypackage.cocoon.ResourceHelper (Size: 1)
Execution flow: 0: aload_0 [InstructionContext] 1: getfield 22
[InstructionContext] 4: invokevirtual 31 [InstructionContext] 7: ifne - 104
[InstructionContext] 10: aload_0 [InstructionContext] 11: invokevirtual 35
[InstructionContext] 14: ldc 37 [InstructionContext] 16: invokeinterface 43
[InstructionContext] 21: ldc 45 [InstructionContext] 23: invokevirtual 51
[InstructionContext] 26: ifeq - 98 [InstructionContext] 29: aload_0
[InstructionContext] 30: getfield 22 [InstructionContext] 33: invokevirtual
55
[InstructionContext]
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Request URI
edit/general/test
cause
org.apache.bcel.verifier.exc.StructuralCodeConstraintException: Instruction
INVOKEVIRTUAL constraint violated:
Class 'com.mypackage.security.SecurityFactory' is referenced, but cannot be
loaded and resolved: 'VERIFIED_REJECTED
Number of LocalVariableTable attributes of Code attribute '' (method 'public
static com.mypackage.security.SecurityFactory getInstance()') exceeds number
of
local variable slots '0' ('There may be no more than one LocalVariableTable
attribute per local variable in the Code attribute.').
'.
InstructionHandle: 33: invokevirtual[182](3) 55
Execution Frame:
Local Variables:
0: com.mypackage.cocoon.security.AuthenticationHandler
1:
2:
3:
OperandStack:
Slots used: 1 MaxStack: 4.
com.mypackage.cocoon.ResourceHelper (Size: 1)
Execution flow:
0: aload_0 [InstructionContext]
1: getfield 22 [InstructionContext]
4: invokevirtual 31[InstructionContext]
7: ifne - 104 [InstructionContext]
10: aload_0 [InstructionContext]
11: invokevirtual 35[InstructionContext]
14: ldc 37 [InstructionContext]
16: invokeinterface 43 [InstructionContext]
21: ldc 45 [InstructionContext]
23: invokevirtual 51[InstructionContext]
26: ifeq - 98 [InstructionContext]
[jira] Updated: (COCOON-1194) FormsTransformer causes NPE
[ http://issues.apache.org/jira/browse/COCOON-1194?page=all ] Pier Fumagalli updated COCOON-1194: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. FormsTransformer causes NPE --- Key: COCOON-1194 URL: http://issues.apache.org/jira/browse/COCOON-1194 Project: Cocoon Type: Bug Components: CocoonForms Versions: 2.1.5 Environment: Operating System: Linux Platform: PC Reporter: Colin Adams Assignee: Colin Adams Attachments: edit-events-template.xml, edit-events-template.xml, event-binding.xml, event-form.xml Trying to transform a form cause a message org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.lang.NullPointerException The message occurs when attempting to porcess the SAX stream coming out of the FormsTransformer - for instance, with the serializer. Inserting a LogTransformer between the FormsTransformer and the serializer (XHTML 1.1) reveals that the last SAX event was: [startPrefixMapping] prefix=null,uri=null -- 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-1242) XML serializer puts DOCTYPE after initial XML comments
[ http://issues.apache.org/jira/browse/COCOON-1242?page=all ] Pier Fumagalli updated COCOON-1242: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. XML serializer puts DOCTYPE after initial XML comments -- Key: COCOON-1242 URL: http://issues.apache.org/jira/browse/COCOON-1242 Project: Cocoon Type: Bug Components: sitemap components Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Emilian LOSNEANU Assignee: Cocoon Developers Team Priority: Minor xml serializer places !DOCTYPE after the comment in the source file. Source: === !-- Comment -- html head/head /html Result: === ?xml version=1.0 encoding=UTF-8?!-- Comment --!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html head/head /html This is what I used in my sitemap.xmap file: map:serializers default=xhtml map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml src=org.apache.cocoon.serialization.XMLSerializer doctype-public-//W3C//DTD XHTML 1.1//EN/doctype-public doctype-systemhttp://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd/doctype-system encodingUTF-8/encoding /map:serializer /map:serializers -- 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-1451) o.a.c.transformation.EncodeURLTransformer doesn't work
[ http://issues.apache.org/jira/browse/COCOON-1451?page=all ] Pier Fumagalli updated COCOON-1451: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. o.a.c.transformation.EncodeURLTransformer doesn't work -- Key: COCOON-1451 URL: http://issues.apache.org/jira/browse/COCOON-1451 Project: Cocoon Type: Bug Components: core Versions: Current SVN 2.2 Environment: Operating System: Mac OS X 10.0 Platform: Macintosh Reporter: Mark Assignee: Cocoon Developers Team Not sure that EncodeURLTransformer is for xml/xslt with no xsp's in the mix, but it certainly doesn't seem to, which is unforturnate as IMO url encoding is a baseline issue. Tested disabling cookies and javascript and no session id or context path appending to links. Same issue with trunk (2.2), 2.1.6, running in jetty and tomcat. map:transformer logger=sitemap.transformer.encodeURL name=encodeURL src=org.apache.cocoon.transformation.EncodeURLTransformer include-name.*/@href|.*/@action|frame/@src/include-name exclude-nameimg/@src/exclude-name /map:transformer ... map:match pattern=foo map:generate src=foo.xml / map:transform src=foo.xsl type=xslt / map:transform src=foo.xsl type=encodeURL / map:serialize type=html / /map:match -- 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-1457) jsp functionality broken in cocoon 2.1.7-dev, Tomcat 5.5.7, jdk1.5.0_01
[ http://issues.apache.org/jira/browse/COCOON-1457?page=all ] Pier Fumagalli updated COCOON-1457: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. jsp functionality broken in cocoon 2.1.7-dev, Tomcat 5.5.7, jdk1.5.0_01 --- Key: COCOON-1457 URL: http://issues.apache.org/jira/browse/COCOON-1457 Project: Cocoon Type: Bug Components: blocks Versions: Current SVN 2.1 Environment: Operating System: Linux Platform: PC Reporter: Mark Eggers Assignee: Cocoon Developers Team Environment === fedora core 3 linux 2.6.10-1.766_FC3 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08) Tomcat 5.5.7 servlet servlet-namejsp/servlet-name servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class init-param param-namefork/param-name param-valuefalse/param-value compilerjavac/compiler /init-param init-param param-namexpoweredBy/param-name param-valuefalse/param-value /init-param load-on-startup3/load-on-startup /servlet Cocoon URL: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 155211 Node Kind: directory Schedule: normal Last Changed Author: sylvain Last Changed Rev: 155210 Last Changed Date: 2005-02-24 09:02:09 -0800 (Thu, 24 Feb 2005) Properties Last Updated: 2005-01-24 11:30:14 -0800 (Mon, 24 Jan 2005) Build = Cocoon builds fine under jdk1.5.0_01 with modifications to tools/targets/init-build.xml to target the 1.5 jdk. 152c152 target=1.5 --- target=1.4 178c178 target=1.5 --- target=1.4 Issue = Accessing http://localhost:8080/cocoon/samples/blocks/jsp/welcome.htm generates NO output: htmlbody/body/html Accessing http://localhost:8080/cocoon/samples/blocks/jsp/welcome.xml generates the following error: Premature end of file column: -1 line: -1 cause: org.xml.sax.SAXParseException: Premature end of file. location: null Stack trace information: org.apache.cocoon.ProcessingException: SAXException while parsing JSPEngine output: org.xml.sax.SAXParseException: Premature end of file. at org.apache.cocoon.generation.JSPGenerator.generate(JSPGenerator.java:97) Caused by: org.xml.sax.SAXParseException: Premature end of file. at org.apache.excalibur.xml.impl.JaxpParser.fatalError(JaxpParser.java:443) The JSP and class files for the page are generated in: $TOMCAT_HOME/work/Catalina/localhost/cocoon/org/apache/jsp/samples/blocks/jsp -- 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-1520) Database / avalon problems
[ http://issues.apache.org/jira/browse/COCOON-1520?page=all ] Pier Fumagalli updated COCOON-1520: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. Database / avalon problems -- Key: COCOON-1520 URL: http://issues.apache.org/jira/browse/COCOON-1520 Project: Cocoon Type: Bug Components: blocks Versions: 2.1.7 Environment: Operating System: other Platform: PC Reporter: Hugo Marcelino Assignee: Cocoon Developers Team Hi developers. My name is Hugo Marcelino, and i come across with this bug. If you setup a connection pool to a database in cocoon.xconf and the connection is not available, you will get the web page working and never terminating, just like it is waiting for an answer. (no timeout). this situation happens if you refresh (ctrl + f5) your page about three times, and at the third time you'll see this happening, but at the first two , it works ok(just doesn't return anything, witch is ok!). This was made with cocoon-2.1.7 and j2sdk1.4.2_08 and with mysql connector For a better cocoon... Hugo Marcelino 31-05-2005 -- 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-1558) [PATCH] Fix for validation-error tag in FormsTemplateTransformer
[ http://issues.apache.org/jira/browse/COCOON-1558?page=all ] Pier Fumagalli updated COCOON-1558: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. [PATCH] Fix for validation-error tag in FormsTemplateTransformer Key: COCOON-1558 URL: http://issues.apache.org/jira/browse/COCOON-1558 Project: Cocoon Type: Bug Components: CocoonForms Versions: Current SVN 2.1 Environment: Operating System: other Platform: Other Reporter: Jochen Kuhnle Assignee: Cocoon Developers Team Attachments: patch-formtransformer.txt Hi, when using validation-error tag, the FormsTemplateTransformer behaves weird: it sometime loses all field values following the first field with validation error. The following patch fixes 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] Updated: (COCOON-1571) [PATCH] NullPointerException in MultiValueField
[ http://issues.apache.org/jira/browse/COCOON-1571?page=all ] Pier Fumagalli updated COCOON-1571: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. [PATCH] NullPointerException in MultiValueField --- Key: COCOON-1571 URL: http://issues.apache.org/jira/browse/COCOON-1571 Project: Cocoon Type: Bug Components: CocoonForms Versions: Current SVN 2.2 Environment: Operating System: other Platform: Other Reporter: Peter Brant Assignee: Cocoon Developers Team Attachments: multivaluefield.patch, sample.zip If the locale is not specified and the selection list is being created dynamically, a NullPointerException can result (in my specific case, it was the DataType implementation using the locale as part of formatting a number). Patch is attached. It just uses the same technique that Field already uses. Patch is against 2.2, but if this could make it into the next 2.1 release too, that would be great. -- 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-1564) [html block] HTMLGenerator doesn't copy POST parameters
[ http://issues.apache.org/jira/browse/COCOON-1564?page=all ] Pier Fumagalli updated COCOON-1564: --- Reverting status to NEEDFORINFO as this was not imported from BugZilla. [html block] HTMLGenerator doesn't copy POST parameters --- Key: COCOON-1564 URL: http://issues.apache.org/jira/browse/COCOON-1564 Project: Cocoon Type: Bug Components: blocks Versions: Current SVN 2.1 Environment: Operating System: other Platform: Other Reporter: Andreas Hartmann Assignee: Cocoon Developers Team On a POST request, request parameters are not copied. -- 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] Migration complete...
Ok, me and Jeff (thanks Jeff) finally finished migrating all bugs (correctly) to Jira... Took a little bit longer than expected, but now I think it's working! :-D I've just finishing re-ordering and renaming versions and components, and locking up some of the oldest version (so that we don't get new bugs in there). So, everything should be up-and running now! :-D Pier smime.p7s Description: S/MIME cryptographic signature
Re: release, trunk and branch now run on cocoon.zone
Bertrand Delacretaz wrote: Le 22 oct. 05, à 08:31, David Crossley a écrit : (there are links to these on http://cocoon.zones.apache.org/) Great idea and thanks for the work, but there are currently two issues: - core documentation on http://cocoon.zones.apache.org/demos/21branch/samples/ results in an error: java.io.FileNotFoundException: /home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/docs/sitemap.xmap (No such file or directory) - http://cocoon.zones.apache.org/demos/trunk/ results in: HTTP ERROR: 404 %2Fdemos%2Ftrunk%2F+Not+Found RequestURI=/demos/trunk/ Powered by Jetty:// I've tried waiting for at least 5 minutes, but no help. HTH. Bye, Helma
Docs are building without errors - future failures will report to list
The docs now have no broken links and are building without errors. I have therefore turned on notifications to this list from the Forrestbot. This means that any internal broken links will cause a message to be sent to this list. It will also indicate if a change in Forrest head or in the daisy installation breaks anything. The build runs every 3 hours at present. I'll leave it at this frequency in the run up to the release, and reduce it after the release. Ross
Re: [JIRA] Migration complete...
Hi, Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla? On 10/24/05, Pier Fumagalli [EMAIL PROTECTED] wrote: Ok, me and Jeff (thanks Jeff) finally finished migrating all bugs (correctly) to Jira... Took a little bit longer than expected, but now I think it's working! :-D I've just finishing re-ordering and renaming versions and components, and locking up some of the oldest version (so that we don't get new bugs in there). So, everything should be up-and running now! :-D Pier -- Patrick Neutiquam erro. Magister mundi sum!
Re: [JIRA] Migration complete...
Patrick Ahles wrote: Hi, Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla? And now those docs are in daisy it is not a simple search and replace to fix that. On the daisy list recently Bruno showed me a cool trick for batch processing of files on Daisy. Bruno, I wonder if a similar technique can be used for this case? Ross
Re: [JIRA] Migration complete...
Ross Gardler wrote: Patrick Ahles wrote: Hi, Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla? And now those docs are in daisy it is not a simple search and replace to fix that. On the daisy list recently Bruno showed me a cool trick for batch processing of files on Daisy. Bruno, I wonder if a similar technique can be used for this case? Search replace are already done manually and I'm finished, took me about 15 minutes. BTW most of the references to Bugzilla are in outdated documents that need scrutiny and rewrites anyway. Bye, Helma
[jira] Created: (COCOON-1656) Update documentation contributing process
Update documentation contributing process - Key: COCOON-1656 URL: http://issues.apache.org/jira/browse/COCOON-1656 Project: Cocoon Type: Task Components: - Documentation Versions: 2.1.8-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Helma van der Linden Priority: Minor The processes of writing and contributing documentation have changed. This makes the current versions of the How to author pages outdated. Tasks to be done: - write down new processes - get agreement/consensus on new processes - identify all pages in Daisy documentation that should be changed because of these processes - adapt all relevant pages in Daisy documentation to reflect new processes (retire if necessary) - if necessary, move the updated pages to the documentation collection and out of the legacydocs collection. -- 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-1657) VelocityGenerator: error when sending string containing ampersand
VelocityGenerator: error when sending string containing ampersand
-
Key: COCOON-1657
URL: http://issues.apache.org/jira/browse/COCOON-1657
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.1.7
Reporter: Andreas Deininger
Take this flowscript:
function velotest() {
cocoon.sendPage(abstract.vm, { test : vmvm } );
}
With abstract.vm being an velocity template processed by the Velocity Generator:
?xml version ?
data$test/data
You receive the following error, due to the occurence of the
ampersand-sign in the vmvm string::
An Error Occurred: The reference to entity vm must end with the ';' delimiter.
This seems to be due to the fact that the sent value is not escaped, i.e.
remains and does not get converted to amp; in the resulting XML.
--
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
cforms: a bugfix and an update
Hi all, While doing some tests on CForms, I found two things I'd like to fix before the release: Static selection-lists produce some location information in HTML pages (view source in form1 sample and search for loc:src). This is clearly a bug and should be fixed. I just realized that I forgot to add the new ft:repeater/ft:repeater-rows that replaces ft:repeater-widget (see [1]) in the FormsTransformer. This isn't really a showstopper, but allows the same template to be used with JXTG or the transformer, and thus less headaches for users that will switch between the two. I have the updated transformer ready on my HD. Shall I commit it? Sylvain [1] http://cocoon.zones.apache.org/daisy/documentation/forms/750.html -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Updated: (COCOON-1630) [M10N] Mavenization Roadmap
[ http://issues.apache.org/jira/browse/COCOON-1630?page=all ] Reinhard Poetz updated COCOON-1630: --- Bugzilla Id: (was: 36999) Component: M10N (was: - Components: Avalon) Description: Container issue to hold everything related to bringing the cocoon 2.2.x. under m2 control. From now on, [M10N] means mavenization. was: Container issue to hold everything related to bringing the cocoon 2.2.x. under m2 control. From now on, [M10N] means mavenization. [M10N] Mavenization Roadmap --- Key: COCOON-1630 URL: http://issues.apache.org/jira/browse/COCOON-1630 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team Container issue to hold everything related to bringing the cocoon 2.2.x. under m2 control. From now on, [M10N] means mavenization. -- 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-1646) [M10N] release plugin
[ http://issues.apache.org/jira/browse/COCOON-1646?page=all ] Reinhard Poetz updated COCOON-1646: --- Bugzilla Id: (was: 37083) Component: M10N (was: * Cocoon Core) Description: we need to be able to produce both a source and binary release. Initially we can use source:jar to produce a source release, it simply jars all sourceDirectory/ locations into separate jars. At the moment the source release is just a zip of an svn checkout. The binary release should have * Javadocs * Daisy/Forrest Docs (whatever docs we end up with after exporting from daisy) * Webapp * Jetty * Scripts was: we need to be able to produce both a source and binary release. Initially we can use source:jar to produce a source release, it simply jars all sourceDirectory/ locations into separate jars. At the moment the source release is just a zip of an svn checkout. The binary release should have * Javadocs * Daisy/Forrest Docs (whatever docs we end up with after exporting from daisy) * Webapp * Jetty * Scripts [M10N] release plugin - Key: COCOON-1646 URL: http://issues.apache.org/jira/browse/COCOON-1646 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team we need to be able to produce both a source and binary release. Initially we can use source:jar to produce a source release, it simply jars all sourceDirectory/ locations into separate jars. At the moment the source release is just a zip of an svn checkout. The binary release should have * Javadocs * Daisy/Forrest Docs (whatever docs we end up with after exporting from daisy) * Webapp * Jetty * Scripts -- 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-1632) [M10N] - osgi integration
[ http://issues.apache.org/jira/browse/COCOON-1632?page=all ] Reinhard Poetz updated COCOON-1632: --- Bugzilla Id: (was: 37001) Component: M10N (was: - Components: Avalon) Description: m2 needs integration with osgi for - compiling blocks - dependency resolution This needs to be checked on m2 and felix mailing lists. was: m2 needs integration with osgi for - compiling blocks - dependency resolution This needs to be checked on m2 and felix mailing lists. [M10N] - osgi integration - Key: COCOON-1632 URL: http://issues.apache.org/jira/browse/COCOON-1632 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team m2 needs integration with osgi for - compiling blocks - dependency resolution This needs to be checked on m2 and felix mailing lists. -- 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-1631) [M10N] - block layout
[ http://issues.apache.org/jira/browse/COCOON-1631?page=all ] Reinhard Poetz updated COCOON-1631: --- Bugzilla Id: (was: 37000) Component: M10N (was: - Components: Avalon) Description: adjust block directory layout and POM according to the block directory structure that was agreed upon. was: adjust block directory layout and POM according to the block directory structure that was agreed upon. [M10N] - block layout - Key: COCOON-1631 URL: http://issues.apache.org/jira/browse/COCOON-1631 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team adjust block directory layout and POM according to the block directory structure that was agreed upon. -- 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-1633) [M10N] - pom corrections
[ http://issues.apache.org/jira/browse/COCOON-1633?page=all ] Reinhard Poetz updated COCOON-1633: --- Bugzilla Id: (was: 37002) Component: M10N (was: - Components: Avalon) [M10N] - pom corrections Key: COCOON-1633 URL: http://issues.apache.org/jira/browse/COCOON-1633 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team Correct POMs so that site:site command runs -- 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-1635) [M10N] - build plugin
[ http://issues.apache.org/jira/browse/COCOON-1635?page=all ] Reinhard Poetz updated COCOON-1635: --- Bugzilla Id: (was: 37004) Component: M10N (was: - Components: Avalon) Description: we need an m2 plugin that can take of the dynamic part of the build for us ie a mechanism that allows us to select blocks, write out a POM and trigger a build using this POM. was: we need an m2 plugin that can take of the dynamic part of the build for us ie a mechanism that allows us to select blocks, write out a POM and trigger a build using this POM. [M10N] - build plugin - Key: COCOON-1635 URL: http://issues.apache.org/jira/browse/COCOON-1635 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team we need an m2 plugin that can take of the dynamic part of the build for us ie a mechanism that allows us to select blocks, write out a POM and trigger a build using this POM. -- 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-1634) [M10N] - archetype example
[ http://issues.apache.org/jira/browse/COCOON-1634?page=all ] Reinhard Poetz updated COCOON-1634: --- Bugzilla Id: (was: 37003) Component: M10N (was: - Components: Avalon) Description: create example webapp archetype, initially based upon core, later maybe add a few blocks with samples to this. was: create example webapp archetype, initially based upon core, later maybe add a few blocks with samples to this. [M10N] - archetype example -- Key: COCOON-1634 URL: http://issues.apache.org/jira/browse/COCOON-1634 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team create example webapp archetype, initially based upon core, later maybe add a few blocks with samples to 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
Re: cforms: a bugfix and an update
On Mon, 2005-10-24 at 14:49 +0200, Sylvain Wallez wrote: Hi all, While doing some tests on CForms, I found two things I'd like to fix before the release: Static selection-lists produce some location information in HTML pages (view source in form1 sample and search for loc:src). This is clearly a bug and should be fixed. I just realized that I forgot to add the new ft:repeater/ft:repeater-rows that replaces ft:repeater-widget (see [1]) in the FormsTransformer. This isn't really a showstopper, but allows the same template to be used with JXTG or the transformer, and thus less headaches for users that will switch between the two. I have the updated transformer ready on my HD. Shall I commit it? yep, +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Closed: (COCOON-1630) [M10N] Mavenization Roadmap
[ http://issues.apache.org/jira/browse/COCOON-1630?page=all ] Reinhard Poetz closed COCOON-1630: -- Resolution: Fixed This issue was only necessary to structure sub-issues in Bugzilla. [M10N] Mavenization Roadmap --- Key: COCOON-1630 URL: http://issues.apache.org/jira/browse/COCOON-1630 Project: Cocoon Type: Bug Components: M10N Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jorg Heymans Assignee: Cocoon Developers Team Container issue to hold everything related to bringing the cocoon 2.2.x. under m2 control. From now on, [M10N] means mavenization. -- 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: svn commit: r326930 - in /cocoon/blocks/forms/trunk: java/org/apache/cocoon/forms/event/ java/org/apache/cocoon/forms/formmodel/ java/org/apache/cocoon/forms/resources/ samples/forms/
Sylvain Wallez wrote: Vadim Gritsenko wrote: - but please mention that when upgrading from 2.1.7 all templates has to be updated to include submit-on-change=false to keep'em forms from breaking: ft id=foo fi:styling submit-on-change=false /ft Sorry, I don't see the point here. The submit-on-change is automatic for those fields that _do have_ change listeners. From my experience, most if not all fields with change listeners have a submit-on-change='true', meaning nothing will change for the vast majority of forms. My experience is inverse: most fields with change listeners have no submit-on-change. The only case where form behaviour will be different will be for fields that have change listeners but no submit-on-change=true in the template. These forms will not be broken, but will roundtrip too much to the server. That's exactly the scenario which I meant. Some forms will be broken, as previously you could rely on fact that form submit happens only once, when form is submitted. Now, you will get multiple form round-trips per single submit. That is significant departure in logic which warrants mentioning. Vadim
[jira] Closed: (COCOON-1641) [Link] RynekMedyczny.pl
[ http://issues.apache.org/jira/browse/COCOON-1641?page=all ] Helma van der Linden closed COCOON-1641: Resolution: Fixed Entry moved to updated version in Live sites and URL updated. [Link] RynekMedyczny.pl --- Key: COCOON-1641 URL: http://issues.apache.org/jira/browse/COCOON-1641 Project: Cocoon Type: Bug Components: - Documentation Versions: 2.1.7 Environment: Operating System: other Platform: Other Reporter: Wojciech Gdela Assignee: Cocoon Developers Team URL of the website: http://www.rynekmedyczny.pl Title of the website: RynekMedyczny.pl Cocoon version used: 2.1.7 Short summary: health care institution portal (in 4 languages) How can we verify this site is actually built with Cocoon? See HTTP headers - If you have already provided the same/a similar link for the LiveSites pages, please state it here and indicate if this link should be replaced with the above information or if it should be kept as well. Old link is under Cocoon 2.1: RynekMedyczny.pl -- 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-1656) Update documentation contributing process
[ http://issues.apache.org/jira/browse/COCOON-1656?page=all ] Helma van der Linden reassigned COCOON-1656: Assign To: Helma van der Linden Update documentation contributing process - Key: COCOON-1656 URL: http://issues.apache.org/jira/browse/COCOON-1656 Project: Cocoon Type: Task Components: - Documentation Versions: 2.1.8-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Helma van der Linden Assignee: Helma van der Linden Priority: Minor The processes of writing and contributing documentation have changed. This makes the current versions of the How to author pages outdated. Tasks to be done: - write down new processes - get agreement/consensus on new processes - identify all pages in Daisy documentation that should be changed because of these processes - adapt all relevant pages in Daisy documentation to reflect new processes (retire if necessary) - if necessary, move the updated pages to the documentation collection and out of the legacydocs collection. -- 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-1525) [Link] SIL Journal of Translation
[ http://issues.apache.org/jira/browse/COCOON-1525?page=all ] Helma van der Linden closed COCOON-1525: Resolution: Fixed Info is added the live sites page of 2.1.2 [Link] SIL Journal of Translation - Key: COCOON-1525 URL: http://issues.apache.org/jira/browse/COCOON-1525 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.2 Environment: Operating System: All Platform: All Reporter: Lars Huttar Assignee: Cocoon Developers Team Priority: Minor The SIL Journal of Translation is an online, peer-reviewed journal of translation theory and practice. The Journal of Translation aims to publish articles reflecting recent trends in translation theory and practice, including but not limited to exegesis, communication, text-linguistics, and cognitive linguistics. The Journal of Translation is published three times per year by SIL International. The Journal is distributed without subscription via the World Wide Web. Articles are distributed in the form of PDF files that may be freely downloaded. -- 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-1628) polarbear's family site
[ http://issues.apache.org/jira/browse/COCOON-1628?page=all ] Helma van der Linden updated COCOON-1628: - If you want this site to be added to the live site pages, please provide more information. See http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed on how to enter the information. Note, copy the information in http://issues.apache.org/jira/browse/COCOON-1349 to a new entry here and answer the questions. polarbear's family site --- Key: COCOON-1628 URL: http://issues.apache.org/jira/browse/COCOON-1628 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Milan D. Andrejevic Assignee: Cocoon Developers Team Priority: Minor (offline generated) unable to host live site -- 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: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ s
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
I see several problems here:
- SourceNotFoundException is a nominal case (BTW why not using
Source.exists()?) and should not log an exception
* Source.exists() will not work here:
SitemapSource:
/**
* Returns true always.
* @see org.apache.excalibur.source.Source#exists()
*/
public boolean exists() {
return true;
}
BlobSource:
/**
* @see org.apache.excalibur.source.Source#exists()
*/
public boolean exists() {
// FIXME
return true;
}
That's why SourceNotFoundException is a nominal case: some source
implementations cannot say beforehand if they exist or not.
So? I don't see your point.
That can be changed though: BlobSource can be fixed by querying the DB
in exists(), and SitemapSource can tell if a pipeline was built.
Agreed.
* Exception is *not* logged (in the INFO level, that is):
+} else if (getLogger().isInfoEnabled()) {
+getLogger().info(Bundle + sourceURI + not
loaded: Source URI not found);
+}
* Exception *must* be logged if Category is in DEBUG
level - exactly what you would expect if you are trying to
debug i18n component. Anything else is counter productive
and counter intuitive (what you would do if you need to see
those exeptions? Set a breakpoint? Patch implementation?
Roll your own implementation?)
- Bad formed XML files and other serious exceptions are semi-silently
ignored. By semi-silently, I mean they're just logged and don't
bubble up higher in the call stack, thus giving the false impression
that the system works.
Such exceptions must not bubble up upstream: if exception is let
through, your whole site goes down simply due to single bug in i18n
catalogue. With existing exception handling, i18n (and your whole
site) continues functioning with older version of the catalogue, but
reports an error into the log file (that's what you've got monitoring
for). That's the i18n behaviour as it was originally designed. See
Keep existing loaded values comment.
Ok. So you mean that i18n allows broken message files to exist?
Exactly.
This is
contradictory with *all* other hot-reload behaviours in Cocoon: if an
XSLT, a template or sitemap are modified and are malformed, an error is
raised and bubbles up (yes, potentially breaking the whole system). We
don't use the cached version of the file if reload fails.
That's why I find the way i18n handles this very strange. Or does it
mean message dictionaries are not considered on an equal stand with
other application files, and are allowed to be buggy and changed live on
the production server without testing beforehand? This really doesn't
sound good to me...
I guess it takes some getting used to it.
OTOH, if source was deleted, it wipes out old values, as that is what
you are expecting it to do in case you want to delete existing catalogue.
Right.
I will fix the 1st point (it scares my users to see all this in the
logs), and would really understand the rationale for the second.
If fix means always drop original exception, -1: Original exception
must be logged somewhere in case DEBUG is turned on (tell your users
to use INFO or WARN level - DEBUG is for *debugging*).
Problem is that SourceNotFoundException is a *nominal* case indicating
that the source doesn't exist, and which i18n allows since it provides
hierarchical lookup of message files. Logging the exception even in
debug mode gives the false impression that something goes wrong when
this isn't the case.
Then perfect solution is to have a message that reads...
DEBUG (2005-10-17) 15:35.59:744 [i18n] (/foo/bar)
Unknown-Thread/XMLResourceBundleFactory: This is a DEBUG message, you dummy!
SourceNotFoundException happened while resolving a bundle. This bundle probably
does not exist, and that is Ok, so DO NOT WORRY, BUT SET YOUR FREAKING CONFIG TO
INFO! If you are debugging i18n behavior or Cocoon treeprocessor and pipelines,
though, following stacktrace might be useful:
...
Or some such - tweak the wording to your liking...
More general note - ignored exceptions is the single most frustrating experience
you can have with Cocoon in particular and Java in general. Hence I'm proponent
of having the ability to see exception if so desired.
SNFE is used here as a substitute for source.exist(), probably because
two implementations don't have a proper implementation for it. Better
fix the implementations or log the exception only if source.exists()
returns true rather than fill the logs with meaningless exceptions.
Won't argue with that. OTOH, there might be broken sources out there where even
if source.exists() it can still throw SNFE.
You also have to take into an account a situation where source WAS existing at
the moment of .exists(), but was removed before you tried to .getInputStream()
it.
[jira] Closed: (COCOON-1626) [Link] Polska Strefa
[ http://issues.apache.org/jira/browse/COCOON-1626?page=all ] Helma van der Linden closed COCOON-1626: Resolution: Fixed Information is added to Daisy Live sites [Link] Polska Strefa Key: COCOON-1626 URL: http://issues.apache.org/jira/browse/COCOON-1626 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: All Reporter: Grzegorz TaÅczyk Assignee: Cocoon Developers Team Priority: Minor URL of the website: http://www.classifieds.pl Title of the website: Polska Strefa Cocoon version used: 2.1.6 Short summary: Polish website with classified ads How can we verify this site is actually built with Cocoon? Beacause I posted few times since last year on users@cocoon.apache.org ? - How much time did it take to build the site from design to publication? 2 months, but it is still under developement. New important improvements are still pedning. - How much traffic does the site handle? About 40.000 sessions each day - What made you choose Cocoon to build the site? 1. Java 2. XML - What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? I didn't use Flow, CForms, Portal Framework, SQLTransformer or Database Actions etc. It is based on my own Actions, Generators, Readers. Cron Scheduler is an important part there. I decided to use PostgreSQL as database engine. - Can you provide a contact email address if people want further information? [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
Re: cforms: a bugfix and an update
Il giorno 24/ott/05, alle ore 14:49, Sylvain Wallez ha scritto: I have the updated transformer ready on my HD. Shall I commit it? They look like bugfixes to me. +1. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
[EMAIL PROTECTED]: Project cocoon-block-template (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-block-template has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-apples : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - 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-block-template/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [template-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html Work Name: build_cocoon_cocoon-block-template (Type: Build) Work ended in a state of : Failed Elapsed: 18 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-24102005 -Dblock-name=template gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-template (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-block-template has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-apples : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - 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-block-template/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [template-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html Work Name: build_cocoon_cocoon-block-template (Type: Build) Work ended in a state of : Failed Elapsed: 18 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-24102005 -Dblock-name=template gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-midi (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-block-midi has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-midi : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-midi/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [midi-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html Work Name: build_cocoon_cocoon-block-midi (Type: Build) Work ended in a state of : Failed Elapsed: 8 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-24102005 -Dblock-name=midi gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-midi (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-block-midi has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-midi : Java XML Framework Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-midi/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [midi-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-midi/gump_work/build_cocoon_cocoon-block-midi.html Work Name: build_cocoon_cocoon-block-midi (Type: Build) Work ended in a state of : Failed Elapsed: 8 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dbuild=build/cocoon-24102005 -Dblock-name=midi gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[jira] Commented: (COCOON-1628) polarbear's family site
[ http://issues.apache.org/jira/browse/COCOON-1628?page=comments#action_12355622 ] Milan Andrejevic commented on COCOON-1628: -- URL of the website: http://milan.port5.com/ Title of the website: polarbear's family site Cocoon version used: 2.1.7 Short summary: Offline generated, multilingual site. MySql blogs, automatic menu generation from file system. Administration of users, blogs and comments. How can we verify this site is actually built with Cocoon? Well I striped off all namespaces from last serialization :( - I have posted Bug 36988 on ASF Bugzilla. Please replace with this one. The following questions are optional: - Several months. Cocoon user 3 years now. - Don't know. - I tried asp, php, plone, but I found Cocoon most appropriate for the job. - I use file, status, search, jx, forms, directory, xsp, calendar generators; xslt (saxon with xslt 2.0 support), i18n, linkrewriter, paginator, cinclude, write-source transformers; preemptive action; html, links, fo2pdf serializers. Site implements authentication framework, cforms and server-side javascript control flow. Database connection through flow. - [EMAIL PROTECTED] polarbear's family site --- Key: COCOON-1628 URL: http://issues.apache.org/jira/browse/COCOON-1628 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Milan D. Andrejevic Assignee: Cocoon Developers Team Priority: Minor (offline generated) unable to host live site -- 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-block-jcr (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-block-jcr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-jcr : A jcr: protocol for Cocoon Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jcr-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/gump_work/build_cocoon_cocoon-block-jcr.html Work Name: build_cocoon_cocoon-block-jcr (Type: Build) Work ended in a state of : Failed Elapsed: 21 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=24102005 -Dblock-name=jcr gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
[EMAIL PROTECTED]: Project cocoon-block-jcr (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-block-jcr has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-jcr : A jcr: protocol for Cocoon Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [jcr-block.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon-block-jcr/gump_work/build_cocoon_cocoon-block-jcr.html Work Name: build_cocoon_cocoon-block-jcr (Type: Build) Work ended in a state of : Failed Elapsed: 21 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dversion=24102005 -Dblock-name=jcr gump-block [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH:
Re: treeprocessor doesn't resolve variables in all attributes of sitemap nodes
Marc Portier wrote:
Hi there,
just found out that
map:serialize status-code={statusCode} /
kept giving me a statuscode 200 no matter what the value of statusCode was.
as it turns out the SerializeNodeBuilder will in it's buildNode do:
this.node = new SerializeNode(
type,
VariableResolverFactory.getResolver(config.getAttribute(src,
null), this.manager),
VariableResolverFactory.getResolver(config.getAttribute(mime-type, null),
this.manager),
config.getAttributeAsInteger(status-code, -1)
);
which I read as: @src and @mime-type can but @status-code can-not be
resolved from variables
from an end-user POV this difference in handling is quite arbitrary
(meaning: if there are good considerations for this we should document
them well)
Hmm, I see no reason why status-code should not be able to use variables.
SNIP/
./SerializeNodeBuilder.java: mime-type
./SerializeNodeBuilder.java: status-code
Hmm, either your script is not correct, or your statement above :) Can
mime-type use variables or not?
SNIP/
anyone any opinion on these?
maybe it makes sense to look at these with our rule of least
surprise-glasses on?
Yes, I think we should go through all these attributes and see/vote
which ones can be made dynamic.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
DO NOT REPLY [Bug 23615] - XSLTC doesn't work with nodeset functions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=23615. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=23615 --- Additional Comments From [EMAIL PROTECTED] 2005-10-24 16:58 --- New bugs, or modifications to existing bugs should be made using JIRA. Some time ago tracking of bugs and issues moved from bugzilla to JIRA at: http://issues.apache.org/jira Everyone is free to view public issues there, but if you want to create a bug or an issue, or comment on one you will need a JIRA account. Before you create a new JIRA account you should check if one hasn't already been created for you. In the migration from Bugzilla to JIRA, people who had previously created or updated Bugzilla bugs should already have a JIRA Username that is the same as their Bugzilla Username. So you should first enter your Userid in the JIRA login panel and click the Forgot Password link to get the password that JIRA has set for this new account e-mailed to you. Otherwise you will need to create a JIRA account. To find a migrated issue, including this one, the JIRA home page has a text field in which you can enter the old Bugzilla number and go straight to the JIRA issue, for XalanJ2 the issue keys are not numbers of are of the form XALANJ-# where # is a number, but not related to the old Bugzilla number. That makes this particular issue now tracked under XALANJ- Regards, Brian Minchau -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [RT] Is Cocoon Obsolete?
On 10/23/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Peter, thanks so much for this, great plug for me to start. No problem, I was wired on coffee after a nice long dinner party and unable to sleep and I had wanted to revive this thread for some time... Just a couple of comments: snip/ I've got a gut feeling for what we need, some of it resonates with what you post here, but I've personally grown sort of attached to Cocoon, so first off, I'd have to answer the subject line with a resounding no. :-) Well, I never really expected people on this list to say yeah, it's crap, I moved on because those who did, would not be here to read that message anyway. Yah, I know that, but even if we did move on I'd watch this list for some time just to make sure the move really made sense and because a lot of good ideas get discussed on this list in any case. snip/ One thing that turns me off about cocoon *today* is the pretty steep *perceived* learning curve. Tough stuff always has long learning curves. If packaged correctly, a naked (no blocks!) cocoon would take no more than an improved Bertrand's SuperSonic Tour. We are getting there. Slowly, painfully, and dragging our userbase with us without abrupt transitions... maybe too slow, I don't know. But I knok that revolutions are hard to manage, so I'm not unhappy about the way we are dealing with day to day evolution. Best practices take a long time to emerge. They're also hard to identify when they do emerge. The Cocoon community probably spends some extra resources chasing dead ends (and thus part of your point), but over all I think there are few communities doing much better (I don't think the scope of Ruby on Rails is large enough to qualify yet, though it's nailed one or two best practices.) But I think we collective lack a vision for what's coming up next and I feel this as a weakness. Yah, I'd agree, Cocoon is big, there are a lot of competing visions involved. snipgood client things, academic communities discussion/snip What we really need? - back end legacy connectors. I can do that with JBoss; - 100% 24/7 rock solid transaction management and data persistence. I can do that with JBoss and some commercial (or maybe even OS) RDB; - flexible data translation and extraction. I can do that with Saxon; - involving, low error, client side interaction: I can do that with AJAX and the rest of the browser stuff that you mention. So why do I want Cocoon (Java or similar glue is assumed)? Because I still need some sort of bridge from the first three things to the last. Correct. We ended up writing our own... and it was no more than 50Kb of java code. Since for us size matters, cocoon was not able to replace that with such little space... but others were the turn offs... the fact that RDF and XML have a serious impedence mismatch. I have been tasked to find a solution for this problem and now I think I have found one. Go on??? For us it's also got to do the security thing as part of the glue... I need a really efficient action dispatcher. In spite of the fact that many might feel that this is one of the weakest parts of Cocoon, this is what it does better than anything else: client action - map to handler - run business rules - persist results - (begin again) Eventually, I expect some form of generalized Ontology traversal (perhaps the semantic Web) to handle the second step yeah, people will push for that, but I doubt declarative inferenced processing will ever be as predictable as explicit procedures. Should be no difference at some point (maybe a long way out): code is code, graphs are graphs, errors are errors. You can code your assumptions however you wish, but it's the unknowns that cause the problems, not the method of coding. Of course the other issue is efficiency... but darned if I see any real AI stepping up to handle the third step. :-) [even if I'm sure many startups will try to that... and fail ;-)] For the foreseeable future I need some kind of multi-technology mosh pit for that process to work in and currently that looks a lot like Cocoon. I know. It looks a lot like but it's not that and I want to bridge the two. So, you've got something up your sleeve? Do tell... that tells us where the real work is: object mapping, pattern recognition, etc (and the great bugbear; distributed cache management to keep the results fresh but yet responsive). Hmmm, not sure. The client is starting to be able to talk to the humans, next we need a way for the server to truly understand what that interaction means, requires, and implies in a global sense. Not only, but don't worry, I'll come up with something here soon. Ok, we won't be staring our next release cycle for at least 8 months (we're halfway into a big one at the moment) ;-) -- Peter Hunsberger
Re: [JIRA] Migration complete...
Pier Fumagalli wrote: On 24 Oct 2005, at 12:56, Ross Gardler wrote: Patrick Ahles wrote: Hi, Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla? And now those docs are in daisy it is not a simple search and replace to fix that. On the daisy list recently Bruno showed me a cool trick for batch processing of files on Daisy. Bruno, I wonder if a similar technique can be used for this case? Ok that the docs are in Daisy, but how do I go about editing the Book.XML files? I just committed the changes manually in SVN... Will they trigger conflicts upon release? All navigation for the Forrest generated docs is pulled form the Daisy navigation documents. SO to edit what was book.xml you need to log into daisy, go to a page that shows the menu you want to edit. At the bottom of the menu strip is a link that says [Go to navigation document] follow that link. On the resulting page click edit like you normally would and you are presented with a GUI for editing the navigation structure. Ross
Jira - How to...?
I want to create a portal component and move the portal issues into that. How can I accomplish that? I don't see a way to change the component an issue is assigned to or a way to create a new component. Ralph
Re: [RT] Rules for adding blocks and functionality?
Sylvain Wallez wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: We are chosen as committers as induviduals and not as representants for our companies. From a community stand point I would say that it is time to deprecate the SQLTransformer. As a representative for my company I would rather say: no way, we have tons of code that depend on it. It is a complicated question, but I don't think that the answer is: I need it at my work so the rest of you should support it. It is really hard to tell what is still useful and what not. Now, the simple example of the SQLTransformer shows this: most of us seem to agree that it's some legacy component and that flow etc. should be used instead. That is not correct, because of: Now, think of a reporting tool done with Cocoon. This fetches some hundreds of MB out of the database and just displays them. In this case everything other than the SQLTransformer + Stylesheet is simply overkill (ok, XSP+ESQL is fine as well) and too memory/time consuming. SQLTransformer is the only *recommended* choice to do reporting in Cocoon. Agree. The really ugly part of SQLTransformer is its ability to perform insert/updates. Yep, this part should be deprecated... Or at least discouraged. I'm using ESQL in a number of places for publication purposes, and many people agree that ESQL is what keeps XSP alive. We have to build an equivalent for CTemplates. Never used ESQL myself, no comment :-) Vadim
Re: [RT] Rules for adding blocks and functionality?
Upayavira wrote: No it wouldn't, because we wouldn't agree what should go there. My suggestion is to, as you did with the samples, leave all blocks as they are, and start _hightlighting_ the ones we consider to be best practices. Then, after some extended period if time we may decide to purge the ones that have not received any highlighting, but highlighting core blocks works much better than deprecating old blocks that people may be using. (And by way of recommendation of this approach :-) this is the approach that Buddhists throughout the centuries used to deal with teachings that had grown stale. They didn't say that is a bad teaching, they said, hey, we've got a higher teaching.) So, basically, until we've got blocks functioning, and have had them so for _some_ time, we should do nothing more than highlighting and marking up with meta-data for our blocks. Our blocks system and block repository is going to create a new organism (which, yes, could well want a contrib group elsewhere such as Niclas suggested), but I want to allow for that organism to grow, well, organically :-) Amen! Vadim
Re: Jira - How to...?
On 24 Oct 2005, at 16:23, Ralph Goers wrote: I want to create a portal component and move the portal issues into that. How can I accomplish that? I don't see a way to change the component an issue is assigned to or a way to create a new component. There are already two components: The Portal Block and the deprecated Portal-FW block... I'm checking right now, and apparently you don't have the appropriate permissions to do anything in there... But I also see two accounts: which one do you normally use? [EMAIL PROTECTED] or [EMAIL PROTECTED] Pier smime.p7s Description: S/MIME cryptographic signature
Re: cforms: a bugfix and an update
Sylvain Wallez wrote: Hi all, While doing some tests on CForms, I found two things I'd like to fix before the release: Static selection-lists produce some location information in HTML pages (view source in form1 sample and search for loc:src). This is clearly a bug and should be fixed. I just realized that I forgot to add the new ft:repeater/ft:repeater-rows that replaces ft:repeater-widget (see [1]) in the FormsTransformer. This isn't really a showstopper, but allows the same template to be used with JXTG or the transformer, and thus less headaches for users that will switch between the two. I have the updated transformer ready on my HD. Shall I commit it? Please do Vadim
JIRA: let me know your Jira user names...
Please, let me know your preferred Jira accounts, some of them have been duplicated in the import as you've used different email accounts in Bugzilla and Jira when registering. I want to go through and de-dupe the accounts and make sure that y'all have the correct rights to work on our Cocoon Jira project... Pier smime.p7s Description: S/MIME cryptographic signature
Re: treeprocessor doesn't resolve variables in all attributes of sitemap nodes
Carsten Ziegeler wrote: Marc Portier wrote: SNIP/ anyone any opinion on these? maybe it makes sense to look at these with our rule of least surprise-glasses on? Yes, I think we should go through all these attributes and see/vote which ones can be made dynamic. IIRC, this vote was already done at Cocoon 2.0 times. Substitution for component types etc was prohibited on the basis that it makes it easier to implement dynamic pipelines. Vadim
Re: Jira - How to...?
Pier Fumagalli wrote: On 24 Oct 2005, at 16:23, Ralph Goers wrote: I want to create a portal component and move the portal issues into that. How can I accomplish that? I don't see a way to change the component an issue is assigned to or a way to create a new component. There are already two components: The Portal Block and the deprecated Portal-FW block... I'm checking right now, and apparently you don't have the appropriate permissions to do anything in there... But I also see two accounts: which one do you normally use? [EMAIL PROTECTED] or [EMAIL PROTECTED] Pier Please delete [EMAIL PROTECTED] [EMAIL PROTECTED] is where [EMAIL PROTECTED] is directed to. Ralph
Re: JIRA: let me know your Jira user names...
Le 24 oct. 05, à 18:34, Pier Fumagalli a écrit : ...let me know your preferred Jira accounts.. Either [EMAIL PROTECTED] or [EMAIL PROTECTED], whatever's most convenient for you. -Bertrand
Re: Jira - How to...?
Pier Fumagalli wrote: There are already two components: The Portal Block and the deprecated Portal-FW block... Pier The table below is what I see (Sorry for the html). I don't see the portal block. Component/s (with open issues in each component) Versions (with open issues due to be fixed per version) * Cocoon Core 101 - Build System: Maven 7 - Cocoon Forms 79 - Components: Avalon 42 - Components: Sitemap 53 - Documentation 7 - Flowscript 12 - Samples 6 Blocks: (Undefined) 73 Unscheduled 380
[jira] Updated: (COCOON-1359) Portal: attributes not set for local JSR-168 portlets
[ http://issues.apache.org/jira/browse/COCOON-1359?page=all ] Pier Fumagalli updated COCOON-1359: --- Reporter: Ralph Goers (was: Ralph Goers) Portal: attributes not set for local JSR-168 portlets - Key: COCOON-1359 URL: http://issues.apache.org/jira/browse/COCOON-1359 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.6 Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Ralph Goers Cocoon does not set values for attributes javax.portlet.request and javax.portlet.response for JSR-168 portlets running in the Cocoon webapp. This is required by the JSR-168 specification. -- 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-1129) [PATCH] Allow applications access to the start and end of a request
[ http://issues.apache.org/jira/browse/COCOON-1129?page=all ] Pier Fumagalli updated COCOON-1129: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] Allow applications access to the start and end of a request --- Key: COCOON-1129 URL: http://issues.apache.org/jira/browse/COCOON-1129 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: bug28424.patch This patch modifies Cocoon.java to have it call a RequestListener before and after a request if one is defined in Cocoon.xconf. A sample RequestListener is provided . The patch to Cocoon.java isn't the prettiest as I didn't want to put something in the finally block that might cause an exception to get lost. -- 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-1262) [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string.
[ http://issues.apache.org/jira/browse/COCOON-1262?page=all ] Pier Fumagalli updated COCOON-1262: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] JXPathMetaModule incorrectly checks for null parameter (can't happen) instead of empty string. -- Key: COCOON-1262 URL: http://issues.apache.org/jira/browse/COCOON-1262 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Critical Attachments: 31134.patch In trying to upgrade from 2.1.4 to 2.1.5.1 we discovered that the SimpleFormTransformer is now broken. Both our site and the Cocoon sample are failing. The symptom is that none of the initial (default) values are displayed. In addition, sitemap.log contains: WARN(2004-09-08) 14:43.31:102 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/persons': Module does not support attribute. WARN(2004-09-08) 14:43.31:114 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/type': Module does not support attribute. WARN(2004-09-08) 14:43.31:116 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/deposit': Module does not support attribute. WARN(2004-09-08) 14:43.31:118 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/email': Module does not support attribute. WARN(2004-09-08) 14:43.31:119 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/address': Module does not support attribute. WARN(2004-09-08) 14:43.31:130 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/driver': Module does not support attribute. WARN(2004-09-08) 14:43.31:136 [sitemap.transformer.simpleform-instance] (/samples/simpleform/four/index) PoolThread-4/SimpleFormTransformer: A problem occurred acquiring a value from 'jxpath' for '/car/car/go': Module does not support attribute. I have verified that this problem still exists in BRANCH-2.1.X. To reproduce this simply run: http://localhost:/samples/simpleform/four/index The form should have default values but none are there. The same page with 2.1.4 displays the defaults. -- 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-1158) [Patch] Allow any LoggerManager to be used
[ http://issues.apache.org/jira/browse/COCOON-1158?page=all ] Pier Fumagalli updated COCOON-1158: --- Reporter: Ralph Goers (was: Ralph Goers) [Patch] Allow any LoggerManager to be used -- Key: COCOON-1158 URL: http://issues.apache.org/jira/browse/COCOON-1158 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Minor Attachments: cocoon-28860.patch This patch allows Cocoon to use any logger that implements LoggerManager. -- 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-1100) [PATCH]XMLResourceBundleFactory is missing catalogs
[ http://issues.apache.org/jira/browse/COCOON-1100?page=all ] Pier Fumagalli updated COCOON-1100: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH]XMLResourceBundleFactory is missing catalogs --- Key: COCOON-1100 URL: http://issues.apache.org/jira/browse/COCOON-1100 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: patch.diff _select in XMLResourceBundleFactory loops through the directories and locales locating resource bundles. However, it stops when it encounters the first bundle name that doesn't have a locale, missing those that might be in one of the other locations. The provided patch fixes that. -- 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-1002) [PATCH] I18nTransformer Multiple catalog search
[ http://issues.apache.org/jira/browse/COCOON-1002?page=all ] Pier Fumagalli updated COCOON-1002: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] I18nTransformer Multiple catalog search --- Key: COCOON-1002 URL: http://issues.apache.org/jira/browse/COCOON-1002 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: patch.zip This patch allows a message catalogue to be searched in multiple locations. For example, there can be a default catalogue in one directory with a user or client specific catalogue in another directory. The catalogues will be searched in the order of the locations specified still following the locale ordering. eg: Assuming a basename of messages and a locale of en_AU(no variant) and locations of translations/client and translations, the following search will occur: translations/client/messages_en_AU.xml ranslations/messages_en_AU.xml translations/client/messages_en.xml translations/messages_en.xml translations/client/messages.xml translations/messages.xml -- 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-1311) [PATCH] Javaflow JavaInterpreter is not thread safe
[ http://issues.apache.org/jira/browse/COCOON-1311?page=all ] Pier Fumagalli updated COCOON-1311: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] Javaflow JavaInterpreter is not thread safe --- Key: COCOON-1311 URL: http://issues.apache.org/jira/browse/COCOON-1311 Project: Cocoon Type: Bug Components: Blocks: (Undefined) Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: 31854.patch If a page causes two cocoon pipelines to be invoked, each of which contains javaflow, a null pointer exception may occur. This occurs because there is a race condition checking the initialized flag. -- 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-1312) [PATCH] Portal - Page Labels
[ http://issues.apache.org/jira/browse/COCOON-1312?page=all ] Pier Fumagalli updated COCOON-1312: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] Portal - Page Labels Key: COCOON-1312 URL: http://issues.apache.org/jira/browse/COCOON-1312 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Minor Attachments: pagelabel.zip, pagelabel2.zip This patch adds support for page labels in the portal. See Portal Page Labels in the wiki for documentation. -- 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-1264) [PATCH] Portal - generate navigation for non-selected tabs
[ http://issues.apache.org/jira/browse/COCOON-1264?page=all ] Pier Fumagalli updated COCOON-1264: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] Portal - generate navigation for non-selected tabs -- Key: COCOON-1264 URL: http://issues.apache.org/jira/browse/COCOON-1264 Project: Cocoon Type: Improvement Components: Blocks: (Undefined) Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Minor Attachments: 31229.patch, 31229c.patch, 31229e.patch The supplied patch generates named-items when the tab-content aspect is configured to do so. Adding parameter name=child-tag-name value=child-tab-layout/ will cause tabs which are not selected to have their sub-navigation items appear as named-item elements within a child-tab-layout element. This patch allows drop-down lists to be generated for the non-selected tabs. -- 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-1145) [PATCH] Allow XConfToolTask to modify multiple attributes
[ http://issues.apache.org/jira/browse/COCOON-1145?page=all ] Pier Fumagalli updated COCOON-1145: --- Reporter: Ralph Goers (was: Ralph Goers) [PATCH] Allow XConfToolTask to modify multiple attributes - Key: COCOON-1145 URL: http://issues.apache.org/jira/browse/COCOON-1145 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Priority: Minor Attachments: patch-28704.diff The attached patch allows XConfToolTask to modify multiple attributes in a single file. This is very useful in updating the pool parameters. The immplemmentation requires that attributes names start with add-attribute-. What follows the '-' is the attribute name. The value specified for this will become the value of the attribute. For example, the following will modify the pool-max, pool-min, and pool-grow attributes on the file generator. In addition, it suppresses the comments that would normally be inserted. This is useful when several patches are applied, some of which add new content while some only modify attributes. xmap xpath=/sitemap/components/generators/[EMAIL PROTECTED]'file'] add-attribute-pool-max=100 add-attribute-pool-min=25 add-attribute-pool-grow=5 add-comments=false / -- 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-1020) Allow the Authentication Framework to invoke a pipeline during logout
[ http://issues.apache.org/jira/browse/COCOON-1020?page=all ] Pier Fumagalli updated COCOON-1020: --- Reporter: Ralph Goers (was: Ralph Goers) Allow the Authentication Framework to invoke a pipeline during logout - Key: COCOON-1020 URL: http://issues.apache.org/jira/browse/COCOON-1020 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.3 Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: authfw-patch.diff -- 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-1239) [Patch] don't compile sample sources if samples have been disabled
[ http://issues.apache.org/jira/browse/COCOON-1239?page=all ] Pier Fumagalli updated COCOON-1239: --- Reporter: Ralph Goers (was: Ralph Goers) [Patch] don't compile sample sources if samples have been disabled --- Key: COCOON-1239 URL: http://issues.apache.org/jira/browse/COCOON-1239 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Ralph Goers Assignee: Cocoon Developers Team Attachments: 30738.patch Patch to blocks-build.xsl that causes sample source to not be compiled when webapp samples have been disabled. -- 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: release, trunk and branch now run on cocoon.zone
Le 24 oct. 05, à 13:14, hepabolu a écrit : ...Great idea and thanks for the work, but there are currently two issues: - core documentation on http://cocoon.zones.apache.org/demos/21branch/samples/ results in an error: java.io.FileNotFoundException: /home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/docs/ sitemap.xmap (No such file or directory) Thanks for the report - I have removed (in SVN, will be on the zone at the next scheduled update) the core documentation link on http://cocoon.zones.apache.org/demos/21branch/samples/ as the docs are not part of the build anymore. - http://cocoon.zones.apache.org/demos/trunk/ results in: HTTP ERROR: 404 %2Fdemos%2Ftrunk%2F+Not+Found That's because the trunk build failed on the last update: Compiling 685 source files to /home/cdemos/demos/trunk/trunk/build/cocoon/classes /home/cdemos/demos/trunk/trunk/src/java/org/apache/cocoon/components/ blocks/BlockWiring.java:193: ';' expected and + this.location + error: + e.getMessage()); That's the beauty of continuous integration: these demos will be broken when the builds are broken - so the build must be fixed for this to start working again. FYI, people who have access to the zone, the logs of these demos are found in /home/cdemos/demos/NNN/logs where NNN is the demo name, like trunk in this case. -Bertrand
Re: JIRA: let me know your Jira user names...
On 24 Oct 2005, at 17:53, Bertrand Delacretaz wrote: Le 24 oct. 05, à 18:34, Pier Fumagalli a écrit : ...let me know your preferred Jira accounts.. Either [EMAIL PROTECTED] or [EMAIL PROTECTED], whatever's most convenient for you. K... And this time I'll try to avoid the spamming! :-D Pier smime.p7s Description: S/MIME cryptographic signature
Re: [2.1.8 release] all htmlunit tests pass on macosx, how about other platforms?
Le 20 oct. 05, à 10:54, Bertrand Delacretaz a écrit : I have fixed a few things so that all htmlunit-tests pass here (JDK 1.4.2, macosx 10.3.8). It would be cool if people could run these tests on other platforms and report results here... FWIW, I've received a success report off-list, that the tests also pass on winXP / java 1.4.2_09 -Bertrand
Re: [JIRA] Migration complete...
On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote: Le 24 oct. 05, à 13:38, Patrick Ahles a écrit : ...Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla?.. Yes, but we can run script to add a link like http://issues.apache.org/jira/bugzillasearch.jsp?id=8017 as a comment in each bugzilla issue, to point to the new issue in jira. We need this as there are many links to bugzilla issues out there. I hope to do this later this week unless someone beats me to it (Pier: this will need deactivating the closed for bug entry flag in bugzilla temporarily, either you can tell me how to do it or I'll ask for it). I want to have that as well, but I thought that if we run it for something like 1655 bugs (there are that many in Bugzilla ATM), will mean that at least 3310 emails to the mailing list, all people on CC, all reporters, EVERYONE... That's huge spam... I asked on IRC today if someone knew how to add a comment and then close bugs in bugzilla WITHOUT generating any email, and probably SCTemme can help, but this morning he was not there... CCing infrastructure to keep them in the loop, does anyone know howto?? Pier smime.p7s Description: S/MIME cryptographic signature
Re: [JIRA] Migration complete...
On 24 Oct 2005, at 18:29, Sander Temme wrote: On Oct 24, 2005, at 10:16 AM, Pier Fumagalli wrote: On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote: Le 24 oct. 05, à 13:38, Patrick Ahles a écrit : ...Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla?.. Yes, but we can run script to add a link like http://issues.apache.org/jira/bugzillasearch.jsp?id=8017 as a comment in each bugzilla issue, to point to the new issue in jira. We need this as there are many links to bugzilla issues out there. I hope to do this later this week unless someone beats me to it (Pier: this will need deactivating the closed for bug entry flag in bugzilla temporarily, either you can tell me how to do it or I'll ask for it). The 'Closed for Bug Entry' flag only affects the possibility to add new bugs, not to change existing ones. Currently, Cocoon 1 is open for entry in Bugzilla, Cocoon 2 is closed. Yes, we only migrated Cocoon 2, not Cocoon 1 I want to have that as well, but I thought that if we run it for something like 1655 bugs (there are that many in Bugzilla ATM), will mean that at least 3310 emails to the mailing list, all people on CC, all reporters, EVERYONE... That's huge spam... Yes, that would be unfortunate. Extremely much so... I asked on IRC today if someone knew how to add a comment and then close bugs in bugzilla WITHOUT generating any email, and probably SCTemme can help, but this morning he was not there... We can poke directly into the MySQL database, but I want to do that MySELF. I have the MySQL readbugs readonly access, so I can poke around the DB and see what's to do. But unfortunately I don't have an account on AJAX, and therefore cannot connect to the DB... Can someone help? Pier smime.p7s Description: S/MIME cryptographic signature
Re: [JIRA] Migration complete...
On Oct 24, 2005, at 10:16 AM, Pier Fumagalli wrote: On 24 Oct 2005, at 12:46, Bertrand Delacretaz wrote: Le 24 oct. 05, à 13:38, Patrick Ahles a écrit : ...Just to let you know, you are aware of the fact that a lot of links in http://cocoon.apache.org/2.1/index.html and below still point to Bugzilla?.. Yes, but we can run script to add a link like http://issues.apache.org/jira/bugzillasearch.jsp?id=8017 as a comment in each bugzilla issue, to point to the new issue in jira. We need this as there are many links to bugzilla issues out there. I hope to do this later this week unless someone beats me to it (Pier: this will need deactivating the closed for bug entry flag in bugzilla temporarily, either you can tell me how to do it or I'll ask for it). The 'Closed for Bug Entry' flag only affects the possibility to add new bugs, not to change existing ones. Currently, Cocoon 1 is open for entry in Bugzilla, Cocoon 2 is closed. I want to have that as well, but I thought that if we run it for something like 1655 bugs (there are that many in Bugzilla ATM), will mean that at least 3310 emails to the mailing list, all people on CC, all reporters, EVERYONE... That's huge spam... Yes, that would be unfortunate. I asked on IRC today if someone knew how to add a comment and then close bugs in bugzilla WITHOUT generating any email, and probably SCTemme can help, but this morning he was not there... We can poke directly into the MySQL database, but I want to do that MySELF. S. CCing infrastructure to keep them in the loop, does anyone know howto?? Pier -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
calling special ant task for javaflow block
Guys, the javaflow needs to instrument classes at build time. There is an ant task that needs to be called. TBH I am not quite sure where and how to hook that into the current build system best. Any pointers are welcome... cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ s
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
- Bad formed XML files and other serious exceptions are
semi-silently ignored. By semi-silently, I mean they're just logged
and don't bubble up higher in the call stack, thus giving the false
impression that the system works.
Such exceptions must not bubble up upstream: if exception is let
through, your whole site goes down simply due to single bug in i18n
catalogue. With existing exception handling, i18n (and your whole
site) continues functioning with older version of the catalogue, but
reports an error into the log file (that's what you've got
monitoring for). That's the i18n behaviour as it was originally
designed. See Keep existing loaded values comment.
Ok. So you mean that i18n allows broken message files to exist?
Exactly.
Wow. I really dislike that.
This is contradictory with *all* other hot-reload behaviours in
Cocoon: if an XSLT, a template or sitemap are modified and are
malformed, an error is raised and bubbles up (yes, potentially
breaking the whole system). We don't use the cached version of the
file if reload fails.
That's why I find the way i18n handles this very strange. Or does it
mean message dictionaries are not considered on an equal stand with
other application files, and are allowed to be buggy and changed live
on the production server without testing beforehand? This really
doesn't sound good to me...
I guess it takes some getting used to it.
C'mon! What does it mean getting used to it? If it's broken, let's fix
it!! It's too late for 2.1.8, but I'd like this subject to be discussed,
as it really seems a bad thing to me.
snip/
More general note - ignored exceptions is the single most frustrating
experience you can have with Cocoon in particular and Java in general.
Hence I'm proponent of having the ability to see exception if so desired.
Me too, but in this particular case, most exceptions will just say that
the source doesn't exists.
SNFE is used here as a substitute for source.exist(), probably
because two implementations don't have a proper implementation for
it. Better fix the implementations or log the exception only if
source.exists() returns true rather than fill the logs with
meaningless exceptions.
Won't argue with that. OTOH, there might be broken sources out there
where even if source.exists() it can still throw SNFE.
You also have to take into an account a situation where source WAS
existing at the moment of .exists(), but was removed before you tried
to .getInputStream() it. So, SNFE handling still has to be present.
Ok, so what about :
catch (SNFE snfe) {
if (!source.exists()) {
getLogger.info(bundle + source.getURI() + doesn't exist);
} else {
getLogger.info(bundle + source.getURI() + is said to exist
but could not be loaded, sfne);
}
}
That way, we avoid logging an exception that just says that the source
doesn't exist, but still log it whenever there is an inconsistency
between exists() and getInputStream(), whatever its cause.
Deal?
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
HSQLDB broken on the zone
Hi all, Up to now, I couldn't see the SQL samples running on the zone. It says : java.sql.SQLException: Connection is broken: Transfer corrupted at org.hsqldb.jdbc.Util.sqlException(Unknown Source) at org.hsqldb.jdbc.jdbcConnection.getAutoCommit(Unknown Source) 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.apache.avalon.excalibur.datasource.AbstractJdbcConnection.invoke(AbstractJdbcConnection.java:397) Any hint? Thanks, Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [IMP] Code freeze starts tonight
Ralph Goers wrote: Out of curiosity, when exactly does tonight begin? Sorry, overlooked this one... :) tonight meant the end of the day, MET - will be more specific next time. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[M10N] new pom structure
I've just commited a new pom structure for the forms block. It looks like this src/blocks/ pom.xml -- contains all block modules /forms pom.xml -- modules for this block + all lib dependencies /trunk pom.xml -- implementation, depends on ../pom.xml /samples pom.xml -- sample related stuff, depends on impl /test Once we've finalized the pom and block directory structure i'll convert the rest of the blocks, no point in doing every step for all 60 blocks. Further, the root pom now only has following modules : modulecore/module modulecore/test-core/module modulewebapp/module modulesrc/blocks/module modulesrc/mocks/module There is another multi-module pom in src/blocks that contains all the block modules then. Regards Jorg
Re: [M10N] new pom structure
Jorg Heymans wrote: I've just commited a new pom structure for the forms block. It looks like this src/blocks/ pom.xml -- contains all block modules /forms pom.xml -- modules for this block + all lib dependencies /trunk pom.xml -- implementation, depends on ../pom.xml /samples pom.xml -- sample related stuff, depends on impl /test Once we've finalized the pom and block directory structure i'll convert the rest of the blocks, no point in doing every step for all 60 blocks. Hmm, shouldn't /forms/pom.xml also be versioned? It might be that a branch has different modules than trunk, I think. I'm all for a unified directory layout where possible. I can imagine some blocks will not fit into this. For example the portal block will consist of several modules (core, portlet support, wsrp support, castor support, db support and so on), and perhaps several samples. But I think with m2 and the hierarchy of poms this doesn't really matter. Further, the root pom now only has following modules : modulecore/module modulecore/test-core/module modulewebapp/module modulesrc/blocks/module modulesrc/mocks/module There is another multi-module pom in src/blocks that contains all the block modules then. Great Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: calling special ant task for javaflow block
the javaflow needs to instrument classes at build
time. There is an ant task that needs to be called.
TBH I am not quite sure where and how to hook that
into the current build system best.
Which ant task is this? I'm asking because we would want to do this in
the maven build as well.
This is from the javaflow maven.xml
postGoal name=test:compile
ant:path id=rewrite.classpath
ant:path refid=maven.dependency.classpath/
ant:pathelement path=${maven.build.dest}/
/ant:path
ant:taskdef name=rewrite
classname=org.apache.commons.javaflow.ant.AntRewriteTask
classpathref=rewrite.classpath
/
rewrite srcDir=target/test-classes dstDir=target/test-classes
includes
include**/*Flow*.java/include
/includes
/rewrite
/postGoal
There is still a bug in the pattern matching code.
But I suspect that's a minor thing.
cheers
--
Torsten
PGP.sig
Description: This is a digitally signed message part
Re: JIRA: let me know your Jira user names...
On 24.10.2005 18:34, Pier Fumagalli wrote: Please, let me know your preferred Jira accounts, some of them have been duplicated in the import as you've used different email accounts in Bugzilla and Jira when registering. I want to go through and de-dupe the accounts and make sure that y'all have the correct rights to work on our Cocoon Jira project... Could it be that there are two accounts for me? One created by hand long time ago and another one now imported? But both should run on the same email address. Jörg
Re: Identifier used in FragmentExtractorTransformer
On 24.10.2005 08:50, Bart Molenkamp wrote: So what is your solution? I can't find it in the mail archive... They are added as comments to the bug which can now be found at Jira: http://issues.apache.org/jira/browse/COCOON-1148 Jörg Van: Joerg Heinicke Verzonden: vrijdag 21 oktober 2005 23:14 How is this problem related to caching? It is not that hard for me to provide a patch which just generates a new identifier, but I'm wondering if it breaks caching... It is related to caching as the cache key is only based on the request uri and the fragment id. So with always the same uri and id you will always get the same content from the cache. Unfortunately nobody ever responded to my proposals about fixing it. Jörg
Re: [IMP] Code freeze starts tonight
Carsten Ziegeler wrote: Ralph Goers wrote: Out of curiosity, when exactly does tonight begin? Sorry, overlooked this one... :) tonight meant the end of the day, MET - will be more specific next time. We should also make an annouce that this is the testing week and invite people to checkout the SVN and test. Otherwise, people will just hold their breath and wait for the release to happen. I can do it if you want. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [IMP] Code freeze starts tonight
Le 24 oct. 05, à 21:24, Sylvain Wallez a écrit : ..We should also make an annouce that this is the testing week and invite people to checkout the SVN and test. Otherwise, people will just hold their breath and wait for the release to happen. I can do it if you want... If you do, please also mention that people can also test at http://cocoon.zones.apache.org/demos/21branch/ -Bertrand
