Re: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
Hi folks, +1 for 1.5. If in the future we have the need to move to a more recent version (ie: because a patch), then we should discuss it. Best Regards, Antonio Gallardo. On 07/10/16 03:46, Francesco Chicchiriccò wrote: > Hi all, > as recently noticed during the (unfortunately rejected) patch for > COCOON-2354 [1], it might make sense to upgrade the current minimum > JDK requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some > upgrades and help Cocoon 2.1 living in the modern world. > > Besides 3rd part library updates, some work could be needed to upgrade > our Java code, so help would be appreciated. > > WDYT? > Regards. > > [1] > https://lists.apache.org/thread.html/c03a2390ddd45b801a25e9946a49276693652870f4f4fbe732d8@%3Cdev.cocoon.apache.org%3E >
Re: cocoon-sample home page
Hi Peter, I was wondering if we should care much about it. I found a link with the result of the most common used browsers: http://html5test.com/results.html Perhaps we can move to HTML5 and use a bare minimum of it. :) Best Regards, Antonio Gallardo. On 05/01/12 14:17, Peter Hunsberger wrote: I like the look, what's the non HTML 5 / CSS 3 fallback do or look like? Peter Hunsberger On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.com mailto:robby.pelss...@nxp.com wrote: Hi guys, I took a stab at giving the sample home page a more modern look using htm5 /css3. I was wondering what you think about it so far and if I can commit my changes. Robby
Re: How to use newer version of batik?
Hi Brecht, Which version of cocoon do you use? Best Regards, Antonio Gallardo. On 04/05/11 02:40, Brecht Schoolmeesters wrote: Hello, we are using cocoon to generate png images from svg format. We use cocoon + batik + some xslt tranformations (Saxon) to do this. I found that cocoon uses batik 1.6.1, but there was a bug in that version: when a special character, eg é, appeared as the second or later character in a string, the rendering would fail with a java.lang.ArrayIndexOutOfBoundsException. More info: https://issues.apache.org/bugzilla/show_bug.cgi?format=multipleid=38158 https://issues.apache.org/bugzilla/show_bug.cgi?format=multipleid=38158 This bug was fixed in version 1.7, so now my question: is it possible to create a new block in the repo that uses batik 1.7, or is it possible for me to include this newer version? I don't have a lot of experience with using cocoon/blocks. thanks in advance, Brecht
Re: About SendMailTransformer
Hi, Based on the posted error, it means you are not running in your machine a mail server in the same machine: Could not connect to SMTP host: localhost, port: 25 Best Regards, Antonio Gallardo. On 01/04/11 13:08, Hemangi Dua wrote: Hi This is the first time I am working on cocoon. I am working on project which is already build bu someone else. They have used SendMailTransformer for Contact-us Initially website was hosted on hostjava.net server, now I am trying to run it on my local machine. Now all pages, xslts and css are working fine, but when I fill contact-us form and click on submit button, it shows an error Could not connect to SMTP host: localhost, port: 25 May be port 25 of hostjava(where website was hosted previously) was configure accordingly. As I am new to cocoon I am confuse between 1. Where to mail.jar and activation.jar file 2. I have more than WEB-INF/lib, so in which folder I have to add there jar file. 3. How to configure port 25 I am using Tomcat as a server. So please let me know how can I solve this problem Thanks in advance Hemangi In a Day, When u dont come across any PROBLEMS, u can be sure that u r traveling in a WRONG path... Swami Vivekananda
[jira] Commented: (COCOON-2285) Strange behavior of multfieldvalue
[ https://issues.apache.org/jira/browse/COCOON-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12861859#action_12861859 ] Antonio Gallardo commented on COCOON-2285: -- Would you post a sample of the issue? Strange behavior of multfieldvalue -- Key: COCOON-2285 URL: https://issues.apache.org/jira/browse/COCOON-2285 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2 Reporter: Vasily E. Moskaljov Incorrect encoding of Russian characters in fd: multivaluefield if the form fails validation. In addition getValue ().length returns the javascript source of length function instead of the length of the array. Environment: Ubuntu 8.04 LTS, java version 1.6.0_17 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.1.12-dojo1_1-dev
Hi Carlos, I think this is the dojo 1.x latest integration effort branch. Please count with my help to test and commit the work you do. I think there are some other cocoon user that would like to see the latest dojo integrated in to 2.1. Many thanks for taking care of this task. :) Best Regards, Antonio Gallardo. El 22/04/10 12:02, Chávez, Carlos escribió: Hello everyone. Is there any other people working on the integration of dojo ? I'm going to test the branch, but I'm pointing to update to the last stable dojo version. is BRANCH_2_1_X-dojo1_1 the right branch?
Re: [2.1] Is Cocoon 2.1.x officially dead ?
El 23/03/10 16:41, Alfred Nathaniel escribió: BTW, is there still many Cocoon-2.1 users around here ? Best regards, Cédric Damioli At my daytime job I am also still running a number of high-profile websites with Cocoon 2.1.10. So I am very much interested in continuing the 2.1.x branch. But could we agree that JDK1.5 should be the minimum for that future 2.1.12 release? +1 We also still have some applications running on Cocoon. I agree a release is missing, but the trunk is pretty stable. I would like to add a GSoC project to finish dojo update in 2.1. Perhaps Jeremy can help us with this. Best Regards, Antonio Gallardo. Cheers, Alfred.
Re: Entity escaping in o.a.c.c.serializers.XHTMLSerializer
Hi Andreas,
We hit the same issue some years ago and we found a more pragmatic solution:
In org.apache.cocoon.components.serializers.encoding.XHTMLEncoder add
the line marked with a + sign:
private static final char ENCODINGS[][][] = {
+{ { 39 } , #39;.toCharArray() },
{ { 160 } , nbsp;.toCharArray() },
See:
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Entities_representing_special_characters_in_XHTML
Please let me know if this fix the issue, I will gladly commit the fix.
Best Regards,
Antonio Gallardo.
Andreas Hartmann escribió:
Hi Cocoon devs,
this issue has already been discussed several times, e.g. [1], but
AFAIK has not been resolved yet.
The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the
serializers block in Cocoon 2.1.x escapes all characters with a
corresponding HTML 4.0 character entity reference into this entity
reference. This causes issues with inline JavaScript, since e.g. the
double quotes are transformed to quot; which causes a JavaScript
parsing error. Another minor negative effect is the increased document
size.
If I understand the W3C correctly, see e.g. [2], the recommended
approach is to use the character set of the encoding as far as possible,
and use escapes only in exceptional circumstances. I didn't find a
reason why the XHTMLSerializer uses escapes, but I suspect that it is
related to browser compatibility issues.
Do you think it would make sense to make this behaviour configurable,
e.g.
use-entitiestrue|false/use-entities
Does the XHTMLSerializer in Cocoon 2.2 show a different behaviour?
TIA for any comments!
-- Andreas
[1]
http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360
[2] http://www.w3.org/International/tutorials/tutorial-char-enc/
[jira] Commented: (COCOON-2249) XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors
[ https://issues.apache.org/jira/browse/COCOON-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666254#action_12666254 ] Antonio Gallardo commented on COCOON-2249: -- In the patch MinimalXMLEncoder.java is missing. Would you post it? XHTMLSerializer uses entity references quot; and apos; which cause JavaScript parse errors Key: COCOON-2249 URL: https://issues.apache.org/jira/browse/COCOON-2249 Project: Cocoon Issue Type: Improvement Components: Blocks: Serializers Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Andreas Hartmann Attachments: COCOON-2249-2009-01-21-1601.txt The XHTMLSerializer, or, more specifically, the XHMLEncoder, from the serializers block in Cocoon 2.1.x escapes all characters with a corresponding HTML 4.0 character entity reference into this entity reference. This causes issues with inline JavaScript, since e.g. the double quotes are transformed to quot; which causes a JavaScript parsing error. Another minor negative effect is the increased document size. If I understand the W3C correctly, see e.g. [2], the recommended approach is to use the character set of the encoding as far as possible, and use escapes only in exceptional circumstances. I didn't find a reason why the XHTMLSerializer uses escapes, but I suspect that it is related to browser compatibility issues. Maybe we could make this behaviour configurable, e.g. use-entity-referencestrue|false/use-entity-references [1] http://www.nabble.com/Problem-with-XHTMLSerializers-to1311360.html#a1311360 [2] http://www.w3.org/International/tutorials/tutorial-char-enc/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Entity escaping in o.a.c.c.serializers.XHTMLSerializer
Andreas Hartmann escribió:
Unfortunately it doesn't work for me. The XHTML source contains the
NCR for the ' character which also causes a JavaScript error.
To make it work, it would have to look like this:
private static final char ENCODINGS[][][] = {
{ { 34 } , \.toCharArray() },
{ { 39 } , '.toCharArray() },
But this contradicts the very purpose of the XHTMLEncoder, doesn't it?
You are right, it contradicts the mere purpose of the encoding. However
it looks as a valid pragmatic solution.
On a second review it looks there is a better way to handle this issue.
Please just checkout how the HTMLEncoder avoids encoding the of '
(apos;) and voids to pass the encoding control to super class XHTMLEncoder.
We should move this code directly to XHTMLEncoder and add in the similar
way an exception for the (quot;)
WDYT?
Best Regards,
Antonio Gallardo.
Re: Avoid escaping chars in script/style only in HTMLSerializer? (Re: svn commit: r515096)
Andreas Hartmann escribió: Hi Carsten, cziege...@apache.org schrieb: Author: cziegeler Date: Tue Mar 6 04:11:29 2007 New Revision: 515096 URL: http://svn.apache.org/viewvc?view=revrev=515096 Log: Correctly handle content of script and style tag as cdata for html. is there a particular reason why this change hasn't been applied to the XHTMLSerializer as well? IIUC, the script/style CDATA handling is also defined for XHTML [1]. I think this is a better solution. Please implement it in this way. Move the code from HTMLSerializer to XHTML Serializer. Thanks for taking care of this long standing issue. Best Regards, Antonio Gallardo. [1] http://www.w3.org/TR/xhtml1/#h-4.8
Re: New Spring Maintenance policy
Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? I think changing the rules is not fair at all. That should rings our bells. Most important, our own user base will suffer. Any of our user now have to have in the pocket 16k yearly in order to deploy a cocoon 2.2 based application. That does not sounds good at all. There are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: 'we care about people more than we care about code'. We have to do something. Best Regards, Antonio Gallardo. Antonio Gallardo escribió: Hi folks, Perhaps an old news for some, but I would like to know how you guys think this affects cocoon: http://www.theserverside.com/news/thread.tss?thread_id=50727 Are we going to take some actions on that? Best Regards, Antonio Gallardo.
New Spring Maintenance policy
Hi folks, Perhaps an old news for some, but I would like to know how you guys think this affects cocoon: http://www.theserverside.com/news/thread.tss?thread_id=50727 Are we going to take some actions on that? Best Regards, Antonio Gallardo.
Re: [vote] Java 1.5 as minimal requirement for trunk
Grzegorz Kossakowski escribió: Hello, As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are more and more problems with keeping Java 1.4 compatibility in trunk. After a while it turned out that everybody agrees on the need for dropping Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal required version seems to be the best solution. +1 Best Regards, Antonio Gallardo.
Re: [vote] David Legg as new Cocoon committer
Grzegorz Kossakowski escribió: I would like to propose David Legg as a new Cocoon committer and PMC Member. +1 Best Regards, Antonio Gallardo.
Re: RFC: Using icu4j for number formatting
Jeremy Quinn escribió: Dear All Background: While working on validating number fields for CForms, I am finding that there is a huge number of discrepancies between Dojo's localised number formatting and the ones built-in to Java. These discrepancies are breaking Dojo's ability to perform client-side validation for many Locales. @see http://blog.fiveone.org/2008/07/number-format-hell.html I mention a few ideas for solutions in the comments, but I think I came up with a better one .. com.ibm.icu.* provides equivalents to java.text.DecimalFormat, java.util.Currency etc. that are built using the same CLDR (Common Locale Data Repository) dataset that Dojo is built from. @see http://www.unicode.org/cldr/ . Specifically, Dojo 1.1.1 (current release) uses CLDR 1.5.1 that comes in icu4j version 3.8.1 and Dojo 1.2 will use CLDR 1.6 which comes in icu4j 4.0 (clear upgrade path). If this works, the benefit would be that number formatting would be consistent regardless of the JVM you are using (above 1.4 the minimum icu needs to run). Question: Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor (the baseclass for all Number Formatting convertors), uses java.text.DecimalFormat internally, without exposing the class to the outside (except for one protected Method). If I were to re-implement FormattingDecimalConvertor using icu4j, should I leave the old one alone and create a new icu4jFormattingDecimalConvertor, or work with the original class? If this solves the problem, this would be the only decimal convertor that would work properly with Dojo, so it would seem pointless to leave the old one around, leading to confusion . I ask this because when it comes to Date Convertors, we do have separate ones for icu4j and the built-in date formatters. I agree, it is pointless to have the old around. Thanks Jeremy for your effort! Best Regards, Antonio Gallardo.
Re: [vote] Luca Morandini as new Cocoon committer
Vadim Gritsenko escribió: On Jul 29, 2008, at 1:29 AM, David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. +1. I wonder how he managed to avoid becoming a committer for so long! ;-) +1 I thought he is already a committer. Welcome aboard Luca! Best Regards, Antonio Gallardo. Vadim
Re: [vote] Andreas Hartmann as new Cocoon committer
David Crossley escribió: I propose Andreas Hartmann as a new Cocoon committer and PMC member. +1 Best Regards, Antonio Gallardo
Re: [vote] Thorsten Scherler as new Cocoon committer
David Crossley escribió: I propose Thorsten Scherler as a new Cocoon committer and PMC member. +1 for the pollo! Best Regards, Antonio Gallardo
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
Andrew Savory escribió: Hi, It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. +1 Best Regards, Antonio Gallardo
Re: [vote] Steven Dolg as committer
Reinhard Pötz escribió: Dear community, it's a great honor for me to propose Steven Dolg as a committer. +1 Best Regards, Antonio Gallardo
Re: Broken test-cases due to missing namespace declarations
Grzegorz Kossakowski escribió: Joerg Heinicke pisze: It does not just wrap Xalan's DOMBuilder. It kind of does the same but has a different approach: Both build a DOM from SAX events but while Xalan's does it directly Cocoon's DOMBuilder utilizes a TransformerHandler and a DOMResult for it. Additionally listening capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is more a internal class, it's not part of public API. It's a public class but unless you want to tie your code to Xalan there is no way to instantiate the class. That's what you usually do using SAXTransformerFactory as Cocoon's DOMBuilder does or DocumentBuilderFactory. The names matches more or less by coincidence. Thanks for explanation Joerg! Even I play with Cocoon for some time I don't know low-level details of Xalan but I think it only proves value of Cocoon that hides all these nasty details. :) Our code is not really broken. Usually we call startPrefixMapping() in startDocument() methods of transformers or something like this. It's only broken for the test cases since we just have a look at the component to test without its framework. From a component POV adding start/endPrefixMapping() is the correct solution to encapsulate it. The question I asked was only if these components will ever run outside of their current framework. Personally I prefer the correct approach as well. I see. Then, agreed with you. Anyway, I have taken effort of tweaking our components and test-cases so all of them pass now. You probably already noticed attached patches to COCOON-2155 issue. I would like to see them committed as soon as we can upgrade to Xalan 2.7.1. I have no idea what the different ways mean in regard of getting things done correctly and as fast as possible. I only got the jar from Antonio's commit to 2.1 and put it into my local repository by copying 2.7.0's POM. So the question should be addressed to Antonio: Where the jar of Xalan you committed into 2.1.x branch comes from? :) Hi Gregorz, Sorry for the delayed reply. Xalan as many other jars has different ways to build it. The one we use in cocoon is one of them without including indise the jar some of the other endorsed libraries. Best Regards, Antonio Gallardo.
[jira] Assigned: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-1822: Assignee: Antonio Gallardo MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1822) MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms
[ https://issues.apache.org/jira/browse/COCOON-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12612678#action_12612678 ] Antonio Gallardo commented on COCOON-1822: -- Patch applied to 2.1.12-dev. MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms Key: COCOON-1822 URL: https://issues.apache.org/jira/browse/COCOON-1822 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Simone Gianni Assignee: Antonio Gallardo Priority: Critical Attachments: dojo-doublelist_patch.tar.gz The multi value field with fi:styling list-type=double-listbox relies on forms_onsubmitHandlers to select all items in the right selection list before submitting. In an ajax form, it seems like forms_onsubmit is not installed on the form, so handlers are not called; in forms-field-styling.xsl this is clearly stated : xsl:choose xsl:when test=@ajax = 'true' xsl:attribute name=dojoTypeCFormsForm/xsl:attribute xsl:if test=@ajax = 'true' script type=text/javascriptcocoon.forms.ajax = true;/script /xsl:if /xsl:when xsl:otherwise xsl:attribute name=onsubmitforms_onsubmit(); xsl:value-of select=@onsubmit//xsl:attribute /xsl:otherwise /xsl:choose I don't think installing forms_onsubmit() also on ajax forma is a wise solution, but maybe we should call it from inside the ajax code, or at least check and execute onsubmit_handlers. If not, also the free-form multivalue field editor will not work correctly. What's the best way to fix this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Plugging that big XSP shaped hole
Kamal escribió: Sylvain Wallez wrote: Note that there is a BSFAction that can be used for actions using any of the scripting languages supported by BSF (including JS), but it isn't closely integrated with the flowscript data. What do you mean by closely integrated with Flowscript? Where is the BSFAction? Hi Kamal, I think Sylvain refers to: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/acting/ScriptAction.html This is part of the BSF block in cocoon. There is also a generator, running samples are here: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/bsf/welcome I hope this helps. Best Regards, Antonio Gallardo.
Re: XSP block
This is a thread that for time to time is being discussed. See:
http://markmail.org/message/uzilvg4ww35nmegk
Quoting from my mail in the thread:
As an old XSP user I think XSP is good for some rapid prototyping and
for some small sites (Matthew and Carsten book stated about it clearly).
The problems using XSP in webapp I painfull learned while working with
it. :-(
Best Regards,
Antonio Gallardo.
Kamal Bhatt escribió:
I am not really a committer to Cocoon, but I was wondering about this
whole JXtemplates + Flowscript replaces XSPs advice. I feel that
JXTemplates + Flowscript is a poor substitute. Here are my reasons why:
1. It leads to an explosion in pipelines. Instead of one pipeline, you
now have 2 (at least)
2. There is so much that isn't easily ported to a JXTemplates +
flowscript environment. For example, there is no analogy to xsp:element.
3. No analogous functionality to the esql logicsheet. You basically
have to create your own and for simple queries, this can quickly
become a hassle.
I have put my hand up for (2), and when I find some time I will look
into it. I cannot see any way of rectifying (3), which is unfortnate
because I suspect that is the biggest reason why people will not move
away from XSPs. As for (1), I was wondering if anyone has thought of
creating an extension to JXTemplates to support a new style of
template. One where you can specify a javascript/Java/Ruby/whatever at
the top and the presentation after that. For example, something like
this:
Template
Flow
Javascript
return({content : 123});
/Javascript
/Flow
Presentation
some_content
jx:out value=${content}/
/some_content
/Presentation
/Template
Is this possible? In some cases, I think this will be a neat solution
as you still have a clear separation between logic and presentation,
but you don't need to open three separate files to see what is going
on. Also, I don't see this as a replacement for flowscript, just
another tool in the toolbox that is Cocoon.
Anyway, my 2c.
Moving this discussion from users list (for reference [1]) to dev list.
On 06.06.2008 19:02, Alfred Nathaniel wrote:
Warning: I'm stating my own opinion here, nothing official or
something like that.
There are at least three problems with XSP:
1. No active committer is interested in XSP anymore, and even more,
hardly anyone wants to invest her time in technology that seems to
be deprecated in every dev's head but still block is not officially
marked as deprecated.
I may be not as active as you but I am a committer who is still very
interested in XSP. In may daytime job we have 1000+ XSPs in production
and no intention to drop that technology in the forseeable future. XSP
has its shortcomings and pitfalls but after 7 years experience we know
how to handle that.
2. The only reason why people keep trying to use XSP is that it has
decent documentation on our site and this documentation has no
information about XSP status. We should really explain people that
Templates + Flowscript is much better approach.
I think the reason why XSP appeals to newcomer is that the concept is
familiar from JSP, and it is a combination of the three core
technologies which Cocoon handles extremely well:
XSP = XML + XSLT + Java.
Personally, I still do not consider Flowscript an alternative for
enterprise websites for three reasons:
a.) Serverside JavaScript is an additional level in the technology
stack
you and your team have to master.
b.) I would not bet my head on Rhino being threadsafe, and it is such a
big beast to debug it yourself.
c.) Continuations are a great idea, but how do you know when it is safe
to free the memory?
3. XSP is really old technique and is not maintained by anyone
(again officially, at dev/commits list). I'm not the one willing to
take costs of XSP maintenance in C2.2 therefore I'll probably vote
-1 for any actions leading to release of XSP block for C2.2. This
is my first such a strong voice in this case but I firmly believe
it's a high time have a concrete opinion.
XSP is a really mature technology which hardly needs any maintenance
any
more. The reason why the XSP block (as many other blocks) is not
released yet is actually more of a C2.2 issue than an XSP problem.
Still, I'm open for discussion of course.
I'd prefer to have this sort of discussion on the dev-list.
I completely agree with Alfred. I don't see any reason for not
releasing XSP block. Yes, somebody has to do the actual work. But why
blocking it when somebody puts in the effort? You can estimate the
maintenance costs by looking at the changes in the last years in the
2.1 branch.
Joerg
[1] http://marc.info/?t=12124988641r=1w=4
[jira] Assigned: (COCOON-2209) POI: formatted style regions stop creating style at 2000 rows.
[ https://issues.apache.org/jira/browse/COCOON-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2209: Assignee: Antonio Gallardo POI: formatted style regions stop creating style at 2000 rows. -- Key: COCOON-2209 URL: https://issues.apache.org/jira/browse/COCOON-2209 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Reynaldo Porras Assignee: Antonio Gallardo Attachments: EPStyleRegion_patch.txt See: http://markmail.org/message/knyapjhi362tlln7 Recurrently, people asks about this issue on cocoon dev or user mail list and there has not been answer so far. Attached is the proposed patch to raise the max cell region from 2k to 65k. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2209) POI: formatted style regions stop creating style at 2000 rows.
[ https://issues.apache.org/jira/browse/COCOON-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2209. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) Thanks for the patch. It was applied in cocoon 2.1 branch and 2.2. POI: formatted style regions stop creating style at 2000 rows. -- Key: COCOON-2209 URL: https://issues.apache.org/jira/browse/COCOON-2209 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN), 2.2, 2.2-dev (Current SVN) Reporter: Reynaldo Porras Assignee: Antonio Gallardo Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: EPStyleRegion_patch.txt See: http://markmail.org/message/knyapjhi362tlln7 Recurrently, people asks about this issue on cocoon dev or user mail list and there has not been answer so far. Attached is the proposed patch to raise the max cell region from 2k to 65k. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2208) Race condition in AbstractCachingProcessingPipeline causes threads to hang.
[
https://issues.apache.org/jira/browse/COCOON-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603216#action_12603216
]
Antonio Gallardo commented on COCOON-2208:
--
Is not the same as: https://issues.apache.org/jira/browse/COCOON-1985 ?
Race condition in AbstractCachingProcessingPipeline causes threads to hang.
---
Key: COCOON-2208
URL: https://issues.apache.org/jira/browse/COCOON-2208
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: Sylvain Wallez
Priority: Blocker
There's a race condition in AbstractCachingProcessingPipeline.waitForLock() :
if lock is not null, there is a possibility that the thread that created
the lock releases it before the current thread starts waiting on it (see
below). When this happens, the thread waits forever since no thread will ever
call notify() on the lock.
The very bad effect is that this progressively blocks the entire thread pool
of the servlet engine, which ends up rejecting new incoming connections.
And BTW, calling containsKey() just before get() unneedingly doubles the
number of lookups.
{noformat}
protected boolean waitForLock(Object key) {
if(transientStore != null) {
Object lock = null;
synchronized(transientStore) {
String lockKey = PIPELOCK_PREFIX+key;
if(transientStore.containsKey(lockKey)) {
// cache content is currently being generated, wait for
other thread
lock = transientStore.get(lockKey);
}
}
// START OF RACE CONDITION ZONE
if(lock != null) {
try {
// become owner of monitor
synchronized(lock) {
// END OF RACE CONDITION ZONE
lock.wait();
}
} catch (InterruptedException e) {
if(getLogger().isDebugEnabled()) {
getLogger().debug(Got interrupted
waiting for other pipeline to finish processing, retrying...,e);
}
return false;
}
if(getLogger().isDebugEnabled()) {
getLogger().debug(Other pipeline finished
processing, retrying to get cached response.);
}
return false;
}
}
return true;
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1703) A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter
[ https://issues.apache.org/jira/browse/COCOON-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-1703: - Status: On Hold (was: Open) Another issue of the provided patch is an unaceptable header in PrintUnitsUtils.java: /* * Copyright (c) 2004 Poznan Supercomputing and Networking Center * 10 Noskowskiego Street, Poznan, Wielkopolska 61-704, Poland * All rights reserved. * * This software is the confidential and proprietary information of * Poznan Supercomputing and Networking Center (Confidential Information). * You shall not disclose such Confidential Information and shall use it only * in accordance with the terms of the license agreement you entered into * with PSNC. */ Would you send a fixed patch with an Aapache License version 2.0? A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - Key: COCOON-1703 URL: https://issues.apache.org/jira/browse/COCOON-1703 Project: Cocoon Issue Type: Bug Components: Blocks: POI Reporter: Krystian Nowak Attachments: psnc-v3.1.patch, psnc-v3.patch A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter - in attachment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r662435 - in /cocoon/branches/BRANCH_2_1_X: ./ src/blocks/eventcache/java/org/apache/cocoon/caching/impl/ src/blocks/eventcache/java/org/apache/cocoon/samples/ src/java/org/apache/coco
Hi Andrew,
I am glad to see you back! Please see below:
[EMAIL PROTECTED] escribió:
Author: asavory
Date: Mon Jun 2 06:51:32 2008
New Revision: 662435
URL: http://svn.apache.org/viewvc?rev=662435view=rev
Log:
COCOON-2152 apply fix from Ellis Pritchard; make samples work again
Modified:
cocoon/branches/BRANCH_2_1_X/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java
URL:
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java?rev=662435r1=662434r2=662435view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/blocks/eventcache/java/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java
Mon Jun 2 06:51:32 2008
@@ -34,72 +39,83 @@
/**
* This implementation holds all mappings between Events and PipelineCacheKeys
- * in two MultiHashMap to facilitate efficient lookup by either as Key.
+ * in two MultiValueMaps to facilitate efficient lookup by either as Key.
*
- * @author Geoff Howard ([EMAIL PROTECTED])
* @version $Id$
*/
-public class EventAwareCacheImpl extends CacheImpl implements Initializable,
- EventAware {
-
+public class EventAwareCacheImpl
+extends CacheImpl
+implements Initializable, Startable, EventAware {
+
private ServiceManager m_manager;
- private EventRegistry m_eventRegistry;
+private EventRegistry m_eventRegistry;
+
+// clean-up thread
+private static final Timer timer = new Timer(event-cache-checker,true);
The above constructor is since java 1.5. Would you change the code to
run with java 1.4? Many thanks in advance. :)
Best Regards,
Antonio Gallardo.
Re: Upgrade Cocoon 2.1 to ehcache 1.3
Alec Bickerton escribió: Andrew Savory wrote: Hi, Now that the vote to switch to a more recent baseline JDK has passed, I'd like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx instrumentation. On second thoughts, why not just upgrade to the most recent version. ;-) +1 == 21 February 2008: ehcache-1.4.1 maintenance release BTW, there are also other jars, that might be a worth to update too. Out of hand I recall an issue with the icu.jar. Also eclipse compiler should be updated, etc. :) Best Regards, Antonio Gallardo.
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
Hi Joerg, I am +1. One question, what are supposed to be the default values for both parameters? Best Regards, Antonio Gallardo. Joerg Heinicke escribió: On 27.04.2008 23:43, Joerg Heinicke wrote: 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? No interest or no objections? :) Joerg
Re: [OT] Mac OS X and Java development
Joerg Heinicke escribió: Do you guys all switch to Linux when it comes to Java development? :) Yup! :) Best Regards, Antonio Gallardo
[jira] Assigned: (COCOON-2186) Suggest list .. initial value not being displayed
[ https://issues.apache.org/jira/browse/COCOON-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2186: Assignee: Antonio Gallardo Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Assignee: Antonio Gallardo Priority: Minor For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2186) Suggest list .. initial value not being displayed
[ https://issues.apache.org/jira/browse/COCOON-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2186. Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Suggest list .. initial value not being displayed -- Key: COCOON-2186 URL: https://issues.apache.org/jira/browse/COCOON-2186 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.11 Reporter: imran pariyani Assignee: Antonio Gallardo Priority: Minor Fix For: 2.1.12-dev (Current SVN) For the forms field of type suggest with a suggestion list the initial value is not being displayed ... this dint happen for version 2.1.10 .. but when i upgraded to version 2.1.11 it no longer sets the initial value .. this bug is also present for the sample http://cocoon.zones.apache.org/demos/release/samples/blocks/forms/do-suggest.flow Initial value of the widget is 16, the widget must show Bruno Dumon. fd:datatype base=integer/ fd:initial-value16/fd:initial-value fd:suggestion-list type=javascript after debugging i found out that the widgets value is being set but it isnt passed on to DOJO as initial value when the DOJO widget is created .. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581012#action_12581012 ] Antonio Gallardo commented on COCOON-2163: -- Patch applied with minor fixes in 2.1.12-dev Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Assignee: Antonio Gallardo Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoC_2008] Project ideas
I would like to propose for GSOC2008 a fix for: https://issues.apache.org/jira/browse/COCOON-1579 WDYT? Best Regards, Antonio Gallardo. Reinhard Poetz escribió: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Any other suggestions? (the deadline for project proposals is Monday, 17th of March)
Re: Maintenance Release 2.1.12
Carsten Ziegeler escribió: I would like to cut a 2.1.12 sometime during April. +1 Best Regards, Antonio Gallardo.
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
Carsten Ziegeler escribió: Hmm, ok, we could change this in the main sitemap as a default configuration while leaving it in the java code untouched. However, I still think that this is not needed, if people want to stream huge responses, they should think about what they are doing and configure everything accordingly. I totally agree that we lack documentation here. +1 Best Regards, Antonio Gallardo.
Re: [#COCOON-2168] ResourceReader produces Java Heap Overflow when reading a huge resource - ASF JIRA
1MB Makes sense. Best Regards, Antonio Gallardo. Joerg Heinicke escribió: On 05.03.2008 23:06, Joerg Heinicke wrote: We could argue about another default value than -1 though. Something like 1024^2. What do others think? Shall we change the default value from buffer everything (which lead to the OutOfMemoryError [1]) to something more secure in the sense of avoiding a potential source of error? Besides mentioning it on the changes page we have to set it to a value that's unlikely to be hit with a normal web application to change user application's behavior only in extreme cases. That's why I suggested 1MB. Joerg [1] https://issues.apache.org/jira/browse/COCOON-2168
Re: ResourceReader headers
Hi Joerg, Good catch! I confirm revision 410112 has a bad log, the correct log should be related to COCOON-1266. The diff [1] is just about 1 line: response.addHeader(Vary, Host); I dropped the Vary header because the vary header in IE is broken [2]. Hence using it to stop caching is just a hack. See also[3]. Hope this helps. Best Regards, Antonio Gallardo. [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/reading/ResourceReader.java?r1=155087r2=410112diff_format=h [2] http://lists.over.net/pipermail/mod_gzip/2002-December/006826.html [3] https://issues.apache.org/jira/browse/COCOON-1424 Here is the diff between Vadim code and the Joerg Heinicke escribió: When looking at the history of ResourceReader I also noticed something else: In rev 155087 [1] Vadim did the following change: Move response header initialization into the setup phase. Remove Last-Modified header initialization: this is done in the environment by request from AbstractProcessingPipeline. In the next revision 410112 [2] (but 15 months later) Antonio readded setting the Last-Modified header: Fix COCOON-1840 XMLFileModule: file-specific configuration ignored. The commit message seems to be wrong and the change was not included in the user-provided patch [3]. It rather seems to be COCOON-1266 [4] but the provided and applied patch is older than Vadim's change. I guess we should review this code. The revisions for trunk are 155099 [5] and 410113 [6]. Joerg [1] http://svn.apache.org/viewvc?view=revrevision=155087 [2] http://svn.apache.org/viewvc?view=revrevision=410112 [3] https://issues.apache.org/jira/browse/COCOON-1840 [4] https://issues.apache.org/jira/browse/COCOON-1266 [5] http://svn.apache.org/viewvc?view=revrevision=155099 [6] http://svn.apache.org/viewvc?view=revrevision=410113
Re: xsltc transformer masks exceptions from CIncluded resources
Hi Tobia,
I would like to include the patch to cocoon. One question: Does work the
the patch for xslt and xsltc or just for the latter?
Best Regards,
Antonio Gallardo
Tobia Conforto escribió:
Thank you for your insight.
Actually XSLTC does preserve the cause, but it's wrapped in
TransformerExceptions.
I managed to solve the issue by patching TraxTransformer so that it
removes wrapping exceptions (of SAXException and TransformerException
type, arbitrarily nested) before re-throwing the core exception.
I will leave it to this list to figure out if it's a useful patch to
merge in Cocoon.
It certainly makes the XSLTC transformer much more useable.
But maybe there's a better place to put this un-wrapping code?
Tobia
--- transformation/TraxTransformer.orig 2008-02-26 18:28:23.0
+0100
+++ transformation/TraxTransformer.java 2008-02-27 13:28:27.0
+0100
@@ -29,6 +29,7 @@
import javax.xml.transform.sax.SAXResult;
import javax.xml.transform.sax.TransformerHandler;
+import javax.xml.transform.TransformerException;
import org.apache.avalon.framework.activity.Disposable;
import org.apache.avalon.framework.configuration.Configurable;
@@ -586,8 +587,21 @@
super.endDocument();
} catch(Exception e) {
-Throwable realEx = this.errorListener.getThrowable();
-if (realEx == null) realEx = e;
+Throwable realEx = e;
+while (true) {
+if (realEx instanceof SAXException) {
+Throwable nested = ((SAXException)
realEx).getException();
+if (nested == null)
+break;
+realEx = nested;
+} else if (realEx instanceof TransformerException) {
+Throwable nested = ((TransformerException)
realEx).getException();
+if (nested == null)
+break;
+realEx = nested;
+} else
+break;
+}
if (realEx instanceof RuntimeException) {
throw (RuntimeException)realEx;
[jira] Assigned: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reassigned COCOON-2020:
Assignee: Antonio Gallardo
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2020) CAPTCHA input element should have autocomplete=off
[
https://issues.apache.org/jira/browse/COCOON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2020.
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.12-dev (Current SVN)
Thanks for the patch. :)
CAPTCHA input element should have autocomplete=off
---
Key: COCOON-2020
URL: https://issues.apache.org/jira/browse/COCOON-2020
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.2-dev
(Current SVN)
Reporter: Mark Lundquist
Assignee: Antonio Gallardo
Priority: Trivial
Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN)
The bug summary says it all, and this isn't even enough to bother making a
patch, all it takes is the following lines added to forms-field-styling.xsl
(the diff is from my 2.1.8 vendor branch, but this fix will work in all
Cocoon versions):
forms-field-styling.xsl(working copy)
@@ -55,6 +55,9 @@
/xsl:if
!-- @id:input is what labels point to --
input name=[EMAIL PROTECTED] id=[EMAIL PROTECTED]:input
value={fi:value} title={fi:hint} type=text
+xsl:if test=fi:captcha-image
+ xsl:attribute name=autocomplete select='off'/
+/xsl:if
xsl:apply-templates select=. mode=styling/
/input
xsl:apply-templates select=. mode=common/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
[ https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2158. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) XMLByteStreamCompiler hard-coded limits of 0x Strings prevents large XML documents from being handled in Cocoon --- Key: COCOON-2158 URL: https://issues.apache.org/jira/browse/COCOON-2158 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Priority: Critical Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: cocoon-xmlbytestream-bigstrings.patch, cocoon-xmlbytestream.patch The hard-coded limits in XMLByteStreamCompiler prevent Cocoon from handling large XML documents. See the methods writeString and writeAttributes for the hard coded arbitrary maximums: if (i 0x) throw new SAXException(Index too large); if (attributes 0x) throw new SAXException(Too many attributes); Additionally, the hand-coded bit manipulation is pretty difficult to change in order to work around this. I am attaching a patch for 2.1.11 that updates the existing JUnit test case to reproduce the problem, as well as a fix to the problem that uses the DataInputStream and DataOutputStream for the low-level bit manipulation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-2163: Assignee: Antonio Gallardo Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Assignee: Antonio Gallardo Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2163) Widget Label is not Show/Hide when we change the widget state in ajax mode
[ https://issues.apache.org/jira/browse/COCOON-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-2163: - Fix Version/s: (was: 2.1.12-dev (Current SVN)) Summary: Widget Label is not Show/Hide when we change the widget state in ajax mode (was: Widget Label is not Show/Hide when we change the widget state) Widget Label is not Show/Hide when we change the widget state in ajax mode -- Key: COCOON-2163 URL: https://issues.apache.org/jira/browse/COCOON-2163 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Carlos Chávez Priority: Minor Attachments: widget_states_patch.txt There is an issue when we change the state of the widget. if initially the widget is active and we change the state to invisible the label of the widget is not hided if initially the widget is invisible and we change the state to active the label of the widget is not showed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: usage of cocoon.createObject
Hi Carlos, Thanks for spotting the issue, people might get this code as a best practices. Would you file the issue and include a patch in scarab? I will be glad to commit the fix. Thank you in advance. Best Regards, Antonio Gallardo. Carlos Chávez escribió: Hello All, About the usage of the cocoon.createObject, i notice that on two cocoon sample we did not call the method cocoon.disposeObject for the object created before, is this right ? The sample code is on: 1. src/blocks/lucene/samples/flow.js 2. src/blocks/portal/samples/coplets/basket/basket.js We create the objects: org.apache.cocoon.components.flow.util.PipelineUtil and org.apache.cocoon.samples.LuceneUtil. Cheers, Carlos Chávez.
Re: Updated the release demo to 2.1.11 on cocoon.zones.apache.org
Thanks Bertrand. Best Regards, Antonio Gallardo. Bertrand Delacretaz escribió: FYI, I have updated the release demo at http://cocoon.zones.apache.org/ to run the latest 2.1.11 release of the 2.1.x branch. For more info about how those demos are setup, see /home/cdemos/README.txt on that host. -Bertrand
Re: [ANN] Apache Cocoon 2.1.11 Released
Jeremy Quinn escribió: On 9 Jan 2008, at 17:34, Carsten Ziegeler wrote: Apache Cocoon 2.1.11 Released Many thanks Carsten !! +1. :) Best Regards, Antonio Gallardo.
Re: [Vote] Cocoon Release 2.1.11
Hi Alec, This is a great improvement! However, we cannot use a newer ehcache version, cuz we must keep cocoon 2.1.x branch compatible with java 1.3. :S Currently, we use ehcache 1.2.3. The 1.2.4 did drop support for java 1.3 [1] Best Regards, Antonio Gallardo. [1] http://ehcache.sourceforge.net/changes-report.html#1.2.4RC Alec Bickerton escribió: Carsten Ziegeler wrote: Hi, i've put up the 2.1.11 release at: http://people.apache.org/~cziegeler/releases/cocoon/ I'm just looking through JIRA and note that the version still uses an antiquated version of ehcache. By that I mean, a version that does not do large distributed caching properly. Large caches must be recreated on server restart and fall over when distributed caching is attempted. Simply replacing the ehcache.jar is not a clean solution as ehcache will write all its files to java.io.tmpdir and produce many warnings whenever used. This is an open issue for C2.2, so I feel it would be something that needs to be looked at before a final release. DISCLAIMER: I'm still finding my way around the cocoon codebase and may be missing something obvious to the old hands. :-) Regards, Alec.
[jira] Commented: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
[ https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556039#action_12556039 ] Antonio Gallardo commented on COCOON-2158: -- Code from 2.2 is already backported. Also the testcase was extended to show this issue (in AbstractXMLTestCase.java replace line 59 with 58 - currently commented). XMLByteStreamCompiler hard-coded limits of 0x Strings prevents large XML documents from being handled in Cocoon --- Key: COCOON-2158 URL: https://issues.apache.org/jira/browse/COCOON-2158 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev (Current SVN) Reporter: Eric Meyer Assignee: Antonio Gallardo Priority: Critical Attachments: cocoon-xmlbytestream-bigstrings.patch, cocoon-xmlbytestream.patch The hard-coded limits in XMLByteStreamCompiler prevent Cocoon from handling large XML documents. See the methods writeString and writeAttributes for the hard coded arbitrary maximums: if (i 0x) throw new SAXException(Index too large); if (attributes 0x) throw new SAXException(Too many attributes); Additionally, the hand-coded bit manipulation is pretty difficult to change in order to work around this. I am attaching a patch for 2.1.11 that updates the existing JUnit test case to reproduce the problem, as well as a fix to the problem that uses the DataInputStream and DataOutputStream for the low-level bit manipulation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Cocoon Release 2.1.11
Hi, Not sure if this 1 testcase failing is a showstopper: Unexpected Exception junit.framework.AssertionFailedError: Unexpected Exception at org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase.testExecuteRunnablelonglong(DefaultRunnableManagerTestCase.java:758) WDYT? Best Regards, Antonio Gallardo. Carsten Ziegeler escribió: Hi, i've put up the 2.1.11 release at: http://people.apache.org/~cziegeler/releases/cocoon/ please check, verify and cast your votes. Thanks Carsten
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Hi solprovider,
I am wondering if a simple
filtering=on statement can replace the previous code. I recall issues with
files that become broken on the resources if we use filtering. And also some files we
don't want on the final webapp.
Best Regards,
Antonio Gallardo.
[EMAIL PROTECTED] escribió:
Author: solprovider
Date: Mon Dec 24 14:03:31 2007
New Revision: 606743
URL: http://svn.apache.org/viewvc?rev=606743view=rev
Log:
The build process carefully adds each of the standard files in the webapp
directory. New applications are not included in the build process. No files
need to be excluded. This change copies the entire directory. (COCOON-2074)
Modified:
cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
URL:
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743r1=606742r2=606743view=diff
==
--- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml (original)
+++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon Dec 24
14:03:31 2007
@@ -25,33 +25,9 @@
target name=prepare-webapp depends=blocks, package
mkdir dir=${build.webapp}/
-copy file=${webapp}/welcome.xml tofile=${build.webapp}/welcome.xml filtering=on/
-copy file=${webapp}/not-found.xml tofile=${build.webapp}/not-found.xml
filtering=on/
-copy file=${webapp}/welcome.xslt tofile=${build.webapp}/welcome.xslt
filtering=on/
-copy file=${webapp}/sitemap.xmap tofile=${build.webapp}/sitemap.xmap/
-
-!-- generate sitemap entries
-sitemap-components sitemap=${build.webapp}/sitemap.xmap
source=${java}/
---
-
-copy todir=${build.webapp}/stylesheets filtering=on
- fileset dir=${webapp}/stylesheets
-include name=**/*.xslt/
- /fileset
-/copy
-
-copy todir=${build.webapp}/resources filtering=off
- fileset dir=${webapp}/resources/
-/copy
-
-copy todir=${build.webapp}/WEB-INF filtering=on
- fileset dir=${webapp}/WEB-INF
-include name=entities/**/
-include name=classes/**/
-include name=*.x*/
-include name=properties/**/
- /fileset
-/copy
+ copy todir=${build.webapp} filtering=on
+ fileset dir=${webapp}/
+ /copy
copy file=${build}/${name}.jar
tofile=${build.webapp.lib}/${name}-${version}.jar/
Re: Preparing the 2.1.1 release
Ralph Goers escribió: 2.1.1? How many years ago was that? 4 years ago. Here is the full 2.1 series release dates: Version 2.1 (August 12 2003) Version 2.1.1 (September 05 2003) Version 2.1.2 (September 30 2003) Version 2.1.3 (November 13 2003) Version 2.1.4 (February 12 2004) Version 2.1.5.1 (July 9 2004) Version 2.1.6 (November 19 2004) Version 2.1.7 (March 23 2005) Version 2.1.8 (November 18 2005) Version 2.1.9 (April 7 2006) Version 2.1.10 (December 21 2006) Source: http://cocoon.apache.org/2.1/changes.html Best Regards, Antonio Gallardo. Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten
Re: Preparing the 2.1.1 release
Opss. You are right, I did not see the Carsten's typo. :D In any case, I found interesting to see the dates in a list. :) Best Regards, Antonio Gallardo. Ralph Goers escribió: I can't believe you went to the trouble to list all those Antonio - I was just trying to make a joke! I'm sure Carsten must have meant 2.1.11. Ralph Antonio Gallardo wrote: Ralph Goers escribió: 2.1.1? How many years ago was that? 4 years ago. Here is the full 2.1 series release dates: Version 2.1 (August 12 2003) Version 2.1.1 (September 05 2003) Version 2.1.2 (September 30 2003) Version 2.1.3 (November 13 2003) Version 2.1.4 (February 12 2004) Version 2.1.5.1 (July 9 2004) Version 2.1.6 (November 19 2004) Version 2.1.7 (March 23 2005) Version 2.1.8 (November 18 2005) Version 2.1.9 (April 7 2006) Version 2.1.10 (December 21 2006) Source: http://cocoon.apache.org/2.1/changes.html Best Regards, Antonio Gallardo. Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten
Re: Preparing the 2.1.1 release
Vadim Gritsenko escribió: On Dec 18, 2007, at 11:31 PM, Ralph Goers wrote: I can't believe you went to the trouble to list all those Antonio - I was just trying to make a joke! I'm sure Carsten must have meant 2.1.11. It shows interesting pattern, though: Version 2.1 (August 12 2003) Version 2.1.1 (September 05 2003) Version 2.1.2 (September 30 2003) Version 2.1.3 (November 13 2003) Version 2.1.4 (February 12 2004) Version 2.1.5.1 (July 9 2004) Version 2.1.6 (November 19 2004) Version 2.1.7 (March 23 2005) Version 2.1.8 (November 18 2005) Version 2.1.9 (April 7 2006) Version 2.1.10 (December 21 2006) 4 - 3 - 2 - 2 - 1 And for Cocoon 2.0, sequence was 6 (including betas) - 4 - 1 :) This spots, that our release manager was more diligent. ;) Best Regards, Antonio Gallardo.
Re: Portal block: Cocoon demo site initialization error
Vadim Gritsenko escribió: On Dec 14, 2007, at 3:12 PM, Antonio Gallardo wrote: Hi folks, Hey Antonio! Are you planning on applying your patches to trunk too? Would be nice! :) sure thing! First I need to have a 2.2 working on my machine. :) Please check the link: http://marc.info/?l=xml-cocoon-devm=119763815010936 Thanks. I will wait to the next demo update. I will check tomorrow. :) Vadim Best Regards, Antonio Gallardo.
Re: Portal block: Cocoon demo site initialization error
Thanks Carsten! It works again. Best Regards, Antonio Gallardo. Carsten Ziegeler escribió: Should work again. Carsten
[jira] Commented: (COCOON-2052) Allow Ajax submission of forms with empty upload field
[ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551921 ] Antonio Gallardo commented on COCOON-2052: -- Thanks for the patch. I applied it to 2.1.11-dev. To close the issue, please apply it to 2.2-dev. Allow Ajax submission of forms with empty upload field -- Key: COCOON-2052 URL: https://issues.apache.org/jira/browse/COCOON-2052 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: AjaxForm-upload-patch.txt Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Portal block: Cocoon demo site initialization error
Hi folks, Please check the link: http://cocoon.zones.apache.org/demos/21branch/ I got: Message: Could not find component (key [org.apache.cocoon.portal.impl.PageLabelManager]) Best Regards, Antonio Gallardo.
[jira] Commented: (COCOON-2032) [PATCH] Sort order in paginated repeater
[ https://issues.apache.org/jira/browse/COCOON-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547311 ] Antonio Gallardo commented on COCOON-2032: -- Would you provide a sample for the cocoon demo? [PATCH] Sort order in paginated repeater Key: COCOON-2032 URL: https://issues.apache.org/jira/browse/COCOON-2032 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Attachments: sort_repeater.patch Little improvement to the sort-by paginated repeater command. With this patch the command will togle between sorting ascending, descending and unsorted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1251) XSP compile failure when using Java 1.5 features
[
https://issues.apache.org/jira/browse/COCOON-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-1251.
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
Fixed by Alfrad Nathaniel in:
http://svn.apache.org/viewvc?view=revrevision=555089
XSP compile failure when using Java 1.5 features
Key: COCOON-1251
URL: https://issues.apache.org/jira/browse/COCOON-1251
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.5
Environment: Operating System: Linux
Platform: PC
Reporter: Thomas Zehetbauer
Assignee: Antonio Gallardo
Fix For: 2.1.11-dev (Current SVN)
I am trying to use the new JDK1.5 foreach loop in XSP, basically:
List entries = new ArrayList();
for (Map entry: entries) {
...
}
which causes the following error with the default EclipseJavaCompiler:
// start error (lines 1003-1003) Syntax error on token :, ;
expected
for (Map entry: entries)
{
// end error
or even with the Javac compiler:
/home/tomcat/work/Default/beta.hostmaster.org/_/cocoon-
files/org/apache/cocoon/www/Dictionary_xsp.java:1003: ';' expected.
for (Map entry: entries)
{
Cocoon is running under Tomcat 5.0.28 on j2sdk-1.5.0-beta2-b51.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Bertrand Delacretaz escribió: Agree with Ralph, there's no need to close anything, if people want to fix bugs on older versions that's one of the beauties of open source: no one forces you to upgrade, as long as you're ready to fix what you're using if needed. +1 Best Regards, Antonio Gallardo.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transformation: I18NTransformerTestCase.java I18NTransformerTestCase.java.disabled]
Carsten Ziegeler escribió: [EMAIL PROTECTED] wrote: Author: reinhard Date: Tue Sep 25 01:55:55 2007 New Revision: 579132 URL: http://svn.apache.org/viewvc?rev=579132view=rev Log: disable this testcase since it doesn't run through with Java 1.4. The problem is that the included Spring configuration files can't be found. It seems to be a Maven 2/Java 1.4 related problem. I'm not willing to invest anymore time into this and for that reason I disable the test for the release. Java 1.4 support is really a PITA because any of the committers seems to use it and then it's me who has to deal with that problems. Hmm, although I don't want to start a heated discussion about 1.4 or 1.5 for 2.2 again, I think there is a lot of truth in the above statement. It only makes sense to stick with 1.4 if the people working on and using 2.2 is a critical mass. +1 to switch to java 1.5. :) Best Regards, Antonio Gallardo.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabl
I agree. I am optimistic adn believe people opinions changes with time. I would like to start a new vote since we have now a new jave version scenario in front of us. :) wdyt? Best Regards, Antonio Gallardo. Ralph Goers escribió: Carsten Ziegeler said: Although I guess everyone understood what I meant above, just a clarification: of course I meant that it only makes sense to stick with 1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical mass. There is no doubt that currently there are many people using/develeoping 2.2 in general. We just switched our Cocoon deployment in production from IBM 1.4 to Sun 1.5 and got at least a 25% performance improvement. Java 1.6 is out. It seems nuts to me to continue to target 1.4 on an as yet unreleased new version of Cocoon. However, if you view this as a code change then the voting rules state that a single -1 vetoes the proposal, and we got that before. Unless the -1 is rescinded I fear we will be stuck at 1.4 until 2010. Ralph
Re: [jira] Updated: (COCOON-806) [PATCH]: HSSF Serializer does not process gmr:PrintInformation
Thanks for fixing the versions. Best Regards, Antonio Gallardo. Grzegorz Kossakowski (JIRA) escribió: [ https://issues.apache.org/jira/browse/COCOON-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-806: Fix Version/s: (was: 2.1.11-dev (Current SVN)) 2.1.6 Affects Version/s: (was: 2.1.8) 2.1.6 According to this http://cocoon.apache.org/2.1/changes.html document, it was fixed in Cocoon 2.1.6, not 2.1.11-dev. [PATCH]: HSSF Serializer does not process gmr:PrintInformation Key: COCOON-806 URL: https://issues.apache.org/jira/browse/COCOON-806 Project: Cocoon Issue Type: Bug Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: All Reporter: Antonio Gallardo Assignee: Cocoon Developers Team Fix For: 2.1.6, 2.2-dev (Current SVN) Attachments: EP_Grid.java.diff, EP_Orientation.java.diff, EP_Paper.java.diff, Sheet.java.diff The gmr:PrintInformation element is where we configure all the info related to print configuration of the stylesheet generated. For example: landscape orientation, papelsize, margins, etc. Currenlty the HSSF Serializer is ignoring all the info the user send. Here is a example of the element: gmr:PrintInformation gmr:Margins gmr:top PrefUnit=cm Points=28.3/ gmr:bottom PrefUnit=cm Points=28.3/ gmr:left PrefUnit=cm Points=28.3/ gmr:right PrefUnit=cm Points=28.3/ gmr:header PrefUnit=cm Points=14.2/ gmr:footer PrefUnit=cm Points=14.2/ /gmr:Margins gmr:Scale percentage=100 type=percentage/ gmr:vcenter value=0/ gmr:hcenter value=0/ gmr:grid value=0/ gmr:even_if_only_styles value=0/ gmr:monochrome value=0/ gmr:draft value=0/ gmr:titles value=0/ gmr:repeat_top value=/ gmr:repeat_left value=/ gmr:orderr_then_d/gmr:order gmr:orientationlandscape/gmr:orientation gmr:Header Right= Middle=amp;[TAB] Left=/ gmr:Footer Right= Middle=Page amp;[PAGE] Left=/ gmr:paperA4/gmr:paper /gmr:PrintInformation
Re: [Fwd: Invitación]
Folks, Sorry for the spam. :S Best Regards, Antonio Gallardo.
[jira] Assigned: (COCOON-1440) [poi] color string normalization
[ https://issues.apache.org/jira/browse/COCOON-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reassigned COCOON-1440: Assignee: Antonio Gallardo (was: Cocoon Developers Team) [poi] color string normalization Key: COCOON-1440 URL: https://issues.apache.org/jira/browse/COCOON-1440 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Krystian Nowak Assignee: Antonio Gallardo Priority: Minor Attachments: COCOON-1440.patch, COCOON-1440.patch, ColorCodeTest.java In a constructor of ColorCode (org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements) there could be a normalization check to ensure that even if the color string is in form :: it will be normalized to org.apache.poi.hssf.util.HSSFColor's form which is :0:0. I've spend a lot on debugging to get what's going on... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1440) [poi] color string normalization
[ https://issues.apache.org/jira/browse/COCOON-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-1440. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Thanks for the patch. It was applied with minor changes. Feel free to reopen if needed. [poi] color string normalization Key: COCOON-1440 URL: https://issues.apache.org/jira/browse/COCOON-1440 Project: Cocoon Issue Type: Improvement Components: Blocks: POI Affects Versions: 2.1.6 Environment: Operating System: All Platform: PC Reporter: Krystian Nowak Assignee: Antonio Gallardo Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: COCOON-1440.patch, COCOON-1440.patch, ColorCodeTest.java In a constructor of ColorCode (org.apache.cocoon.components.elementprocessor.impl.poi.hssf.elements) there could be a normalization check to ensure that even if the color string is in form :: it will be normalized to org.apache.poi.hssf.util.HSSFColor's form which is :0:0. I've spend a lot on debugging to get what's going on... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-1958) Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without)
[ https://issues.apache.org/jira/browse/COCOON-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo updated COCOON-1958: - Status: On Hold (was: Open) Would you provide a patch? or the lines numbers you are refering for? Many thanks in advance. Some Errors by serializing with the HSSFGenerator generated Excel-Sheet with style-informations (no Problems without) - Key: COCOON-1958 URL: https://issues.apache.org/jira/browse/COCOON-1958 Project: Cocoon Issue Type: Bug Components: Blocks: POI Affects Versions: 2.1.9 Reporter: Rolf Metternich For building an Excel-Sheet, I have to generate an Excel-Sheet by HSSFGenerator, manulpulate the values by a transformer and serialize as an Excel-Sheet. The first test are: generating an Excel-Sheet and serialize direct. Then, in the optimal case, the Excel-Sheet looks like the original. But there raised some error for which I made a workaround. First there was a NPE for fore- and background-colors by generation. I made a try-catch and set 'new HSSFColor.BLACK().getHexString()' for the foreground-color and 'new HSSFColor.WHITE().getHexString()' for the background when an error occures. This error occures only in cells, where the fore- and background-settings in Excel are automatic and none. patternColor (error on serializing) I set to 'attribute(PatternColor, new HSSFColor.WHITE().getHexString())'; Bold (error on serializing) I set the attribute from 'Short.toString(font.getBoldweight())' to ((font.getBoldweight()=font.BOLDWEIGHT_BOLD ) ? 1:0). With this workaround, the generation-serialization of the Excel-Sheet work, but no images are imported, like a logo-jpg. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GSoC final report
Grzegorz, Thanks for your great contribution! :) Best Regards, Antonio Gallardo.
Re: [vote] Deprecated HTMLArea
Felix Knecht escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to deprecated HTMLArea as WYSIWYG HTML editor, because it's no longer developed and maintained [1]. As replacement different solutions exists (e.g. Xinha, dojo's Editor2). +1 Best Regards, Antonio Gallardo.
[jira] Closed: (COCOON-2097) Old excalibur-sourcereolve is still in lib directory after r557984
[ https://issues.apache.org/jira/browse/COCOON-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2097. Resolution: Fixed Assignee: Antonio Gallardo Fixed. See: http://svn.apache.org/viewvc?view=revrevision=560052 Old excalibur-sourcereolve is still in lib directory after r557984 -- Key: COCOON-2097 URL: https://issues.apache.org/jira/browse/COCOON-2097 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11-dev (Current SVN) Reporter: Richard Frovarp Assignee: Antonio Gallardo Fix For: 2.1.11-dev (Current SVN) The old exaclibur-sourcereolve jar is still present, but no longer referenced in jars.xml. Several people using Lenya have had issues building due to this. Removing the offending jar fixes the issue. I see in r557984 the license was removed for the old version, and cocoon/branches/BRANCH_2_1_X/lib/core/excalibur-sourceresolve-2.1.jar was modified. It would appear that it should have been deleted instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2058:
-
Component/s: (was: * Cocoon Core)
Blocks: Forms
This issue is a cforms issue.
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)
[ https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515928 ] Antonio Gallardo commented on COCOON-2073: -- Updated in 2.1, see: http://svn.apache.org/viewvc?view=revrevision=560056 Upgrade to dojo 0.4.3 (security fixes!) --- Key: COCOON-2073 URL: https://issues.apache.org/jira/browse/COCOON-2073 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for cross-site scripting attacks and the guys at dojo strongly recommend upgrading. As far as I can see, there should be no compatibility issues with Cocoon's dojo widgets. http://dojotoolkit.org/releaseNotes/0.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2027) [PATCH] Handling of empty responses in AJAX Forms with IFrame transport
[ https://issues.apache.org/jira/browse/COCOON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo closed COCOON-2027. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) 2.1.11-dev (Current SVN) Thanks for the patch. It was applied in both branches (2.1.11-dev and 2.2). Feel free to reopen the issue if needed. [PATCH] Handling of empty responses in AJAX Forms with IFrame transport --- Key: COCOON-2027 URL: https://issues.apache.org/jira/browse/COCOON-2027 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Jan Oberst Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: cocoon-iframe-continue.patch We are experiencing problems with Cocoon Forms under following circumstances: - Using an AJAX-form - with file-upload (using the IFRAME Dojo transport accordingly) - using MSIE 6 or 7 - pressing the cancel button In this case, an empty response is send. Because of browser limitations, an empty response is emulated using the bu:continue browser-update construct. Microsoft Internet Explorer expects always HTML response when dealing with the IFrame transport, so it cannot handle the XML-response (bu:continute) generated by Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2031:
-
Component/s: (was: * Cocoon Core)
Blocks: XSP
This is a XSP block issue.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: Blocks: XSP
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:503)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:455)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130
[jira] Updated: (COCOON-2031) Language Exception at Runtime by the attempt to compile a random XSP
[
https://issues.apache.org/jira/browse/COCOON-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2031:
-
Status: On Hold (was: Open)
Hi Sebastian,
The issue seems to be a race condition that was fixed in 2.1.10: (taken from
http://cocoon.apache.org/2.1/changes.html )
XSP block: Fix regression introduced in 2.1.8 that under specific
circumstances logicsheets were not applied, leading to compilation errors. This
manifested itself only if a) two XSPs referred to the same custom logicsheet by
a relative location path, b) the custom logicsheet used another logicsheet, and
c) the built-in logicsheet's namespace was not mentioned in xsp:page. The
compilation errors occurred always when calling the second XSP for the first
time. Fix also race condition which could lead to similar XSP compilation
errors under high load when accessing the same logicsheet for the first time.
Committed by AN.
Let us know if just moving to cocon 2.1.10 fix the issue.
Language Exception at Runtime by the attempt to compile a random XSP
Key: COCOON-2031
URL: https://issues.apache.org/jira/browse/COCOON-2031
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.7
Reporter: Sebastian Wenzky
Priority: Critical
Hi there,
at my topic you have a first imagination about my current (very hard) problem.
But at fist, my enumeration of my software components:
- Cocoon 2.18
- JBoss (Version 4) - Tomcat.
Indeed, i have no explanation, for my confuse problem and i don´t know, what
kind of state occures that. Normally, when cocoon starts at first time there
are no problems. I can go, visit different pages (which will be correctly
compiled) and so on... But sometimes later the error occurs suddenly, without
any real worthwhile exception message to me.
But the tracer in cocoon said to me following text(an excerpt):
ERROR (2007-03-10) 07:44.24:308 [sitemap.handled-errors]
(/jobapp3/content/fhj/user.xsp$user-search$meta-html)
TP-Processor8/ErrorHandlerHelper: Language Exception
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
user_xsp:
ERROR 1 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
name,
name,
CDATA,
pst_id
// start error (lines 1044-1044) Syntax error, insert ) to complete
Expression
);
// end error
this.contentHandler.startElement(
http://apache.org/xsp/request/2.0;;,
...
ERROR 2 (org/apache/cocoon/www/docs/content/user_xsp.java):
...
get-parameter,
xsp-request:get-parameter
);
// start error (lines 1063-1063) Syntax error on token ), delete this
token
);
// end error
if ( pstID != null )
{
...
Line 1044, column 0: Syntax error, insert ) to complete Expression
Line 1063, column 0: Syntax error on token ), delete this token
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:409)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:280)
at
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:385)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:620)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:503)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:455)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:120)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.SwitchSelectNode.invoke(SwitchSelectNode.java:103)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68
Re: [jira] Reopened: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
Hi Felix, You should not feel bad for that. Currently we have only 2 branches: 2.2-dev and 2.1.11-dev. The patch was applied to 2.2-dev but not to 2.1.11-dev, this is why I reopened the issue. Best Regards, Antonio Gallardo. Felix Knecht escribió: Antonio Gallardo (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2065: -- Patch was not applied in cocon 2.1.11-dev. I really fell sorry about this, but I trusted the tag that in 2.1.11-dev it was already fixed. Am I forced to verify that all version marked as fixed are really fixed before closing the issue? I relied on the versions mark as fixed (which was the case for 2.1.11-dev). Felix
[jira] Reopened: (COCOON-2065) huge performance increase of LuceneIndexTransformer on large Lucene indexes
[ https://issues.apache.org/jira/browse/COCOON-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2065: -- Patch was not applied in cocon 2.1.11-dev. huge performance increase of LuceneIndexTransformer on large Lucene indexes --- Key: COCOON-2065 URL: https://issues.apache.org/jira/browse/COCOON-2065 Project: Cocoon Issue Type: Improvement Components: Blocks: Lucene Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Dominique De Munck Assignee: Felix Knecht Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: LuceneIndexTransformer.patch PROBLEM: The LuceneIndexTransformer optimizes the Lucene index every time you add an entry to the index. This slows down enormously the indexing with a large index ! If upon every checkin of a document eg, you use it to update the entry, it will slow down. Eg. I have a Pentium IV 2.4 Ghz, Lucene index contains 10 000 doc. Where the index update only takes say 60ms, the optimize that get's called, can take 7 seconds! SOLUTION: I've created a patch that introduces an option optimize-frequency to determine the frequency of the optimize call. It defaults to 1 (current behaviour), when a user sets it to 50, only once every 50 updates the index will be optimized etc If no optimization is wanted, you can set it to 0. This is compliant to the Lucene documentation (fragment of Lucene FAQ): The IndexWriter class supports an optimize() method that compacts the index database and speedup queries. You may want to use this method after performing a complete indexing of your document set or after incremental updates of the index. If your incremental update adds documents frequently, you want to perform the optimization only once in a while to avoid the extra overhead of the optimization. PATCH INFO: added configuration option + a function needToOptimize() which is called before optimizing. needToOptimize() uses a random function generator, to keep code simple. - when the option is not set, CODE WILL BE EXECUTED AS BEFORE - tested one 2.1.11 SVN branch, but no differences in the main trunk thus can be applied there also. - Updated API docs - if patch accepted, I will also update the Wiki: http://wiki.apache.org/cocoon/LuceneIndexTransformer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
I Joerg,
I wonder if the issue should be closed only for 2.1.11, since the 2.2 is
not released yet.
Best Regards,
Antonio Gallardo.
Jörg Heinicke (JIRA) escribió:
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-2059:
--
Fix Version/s: 2.2-dev (Current SVN)
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
[jira] Commented: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514223
]
Antonio Gallardo commented on COCOON-2058:
--
I am wondering if is a good idea to add priorities to xslt rules for the
default cform rendering. I am thinking for the users that overwrote this rules.
wdyt?
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)
[ https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonio Gallardo reopened COCOON-2073: -- At least in 2.1.11-dev this seems to not being fixed (for Linux?). Add the next line to a any page with dojo and it sends back 0.4.1: dojo.debug(The current version of dojo is: , dojo.version.toString()); Upgrade to dojo 0.4.3 (security fixes!) --- Key: COCOON-2073 URL: https://issues.apache.org/jira/browse/COCOON-2073 Project: Cocoon Issue Type: Improvement Components: Blocks: Ajax Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Assignee: Grzegorz Kossakowski Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for cross-site scripting attacks and the guys at dojo strongly recommend upgrading. As far as I can see, there should be no compatibility issues with Cocoon's dojo widgets. http://dojotoolkit.org/releaseNotes/0.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
I did not explained myself pretty well. It is supposed that all the fixes from a previous version are included in all future releases. Hence, an issue fixed in 2.1.11 is assumed to be fixed in 2.2. or not? Best Regards, Antonio Gallardo. Joerg Heinicke escribió: On 20.07.2007 11:28, Antonio Gallardo wrote: I wonder if the issue should be closed only for 2.1.11, since the 2.2 is not released yet. 2.1.11 is neither. That's also why it is named -dev. We always used to handle it that way. On release the -dev suffix gets removed. This system has only one caveat: If there is a bug found in a dev version and fixed before the next release we end up with the same version in both affects version and fix version after the renaming [1]. It then reads like bug affects 2.1.9, but at the same time bug is fixed in 2.1.9. Joerg [1] http://marc.info/?t=11679544253r=1w=4
[jira] Reopened: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo reopened COCOON-2059:
--
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2059) ajax/common.js makes use of deprecated dojo.animation.Timer
[
https://issues.apache.org/jira/browse/COCOON-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo closed COCOON-2059.
Resolution: Fixed
Fix Version/s: 2.1.11-dev (Current SVN)
ajax/common.js makes use of deprecated dojo.animation.Timer
---
Key: COCOON-2059
URL: https://issues.apache.org/jira/browse/COCOON-2059
Project: Cocoon
Issue Type: Bug
Components: Blocks: Ajax
Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Assignee: Grzegorz Kossakowski
Fix For: 2.1.11-dev (Current SVN)
Following code uses deprecated stuff from dojo 0.4.1:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.animation.Timer);
var timer = new dojo.animation.Timer(delay);
timer.onTick = function() {
Dojo in debug mode says: DEPRECATED: dojo.animation.Timer is now
dojo.lang.timing.Timer 0.5
To fix that, one should simply use:
periodicalUpdate: function(delay, href, target, insertion) {
dojo.require(dojo.lang.timing.Timer);
var timer = new dojo.lang.timing.Timer(delay);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2058) Ambiguous rule match for fi:styling/@submit-on-change
[
https://issues.apache.org/jira/browse/COCOON-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Gallardo updated COCOON-2058:
-
Status: On Hold (was: Open)
Would you post saxon error message?
Ambiguous rule match for fi:styling/@submit-on-change
---
Key: COCOON-2058
URL: https://issues.apache.org/jira/browse/COCOON-2058
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Reporter: Ralph Collett
Priority: Minor
Ambiguous rule match for fi:styling/@submit-on-change between
fi:styling/@submit-on-change and fi:styling/@* in forms-field-styling.xsl
rules when using Saxon. Priority of fi:styling/@submit-on-change should be
set to 1 (as in the fi:styling/@type rule).
--- Starting at line 151 of forms-field-styling.xsl ---
xsl:template match=fi:styling/@* mode=styling
xsl:copy-of select=./
/xsl:template
xsl:template match=fi:styling/@submit-on-change mode=styling
xsl:if test=. = 'true'
xsl:attribute name=onchangeforms_submitForm(this)/xsl:attribute
/xsl:if
/xsl:template
xsl:template match=fi:styling/@list-type | fi:styling/@list-orientation |
fi:styling/@listbox-size | fi:styling/@format |
fi:styling/@layout
mode=styling
!--+
| Ignore marker attributes so they don't go into the resuling HTML.
+--
/xsl:template
xsl:template match=fi:styling/@type mode=styling priority=1
!--+
| Do we have a duplicate semantic usage of @type?
| @type is only a marker for the stylesheet in general, but some of
the
| types must/should be in the HTML output too.
+--
xsl:variable name=validHTMLTypes
select='text hidden checkbox radio password image reset
submit'/
xsl:if test=normalize-space(.) and
contains(concat(' ', $validHTMLTypes, ' '), concat(' ', .,
' '))
xsl:copy-of select=./
/xsl:if
/xsl:template
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
Hi Niclas, as a commiter you can commit it. :) Best Regards, Antonio Gallardo. Niclas Hedhman (JIRA) escribió: [ https://issues.apache.org/jira/browse/COCOON-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niclas Hedhman updated COCOON-1301: --- Reporter: Niclas Hedhman (was: Niclas Hedhman) [Patch] Image Operation Reader -- Key: COCOON-1301 URL: https://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF.
Re: HSSFSerializer
Chan Mei Theng escribió: You mean this ... [EMAIL PROTECTED] is users instead of cocoon-user on the above mail address. Best Regards, Antonio Gallardo
Re: trunk broken?
Oliver, I think we will stay at 1.4 Thank your for your feedback. :) Best Regards, Antonio Gallardo. Olivier Billard escribió: Hello there, This is my humble case :), but we are planning to use Cocoon 2.2, and cannot decide (customer does) on Java version, that is strongly likely to be Java 1.4... Because our Cocoon application will be embedded into a bigger existing software architecture based/tested/deployed on Java 1.4. They are some cases where you cannot do it in another way, unfortunately, Antonio :)... I personally think (in a Cocoon user POV) that this should be planned, announced far before doing this, so users like me can plan for it and decide knowing the consequences.
Re: trunk broken?
Andrew Stevens escribió: Date: Thu, 7 Jun 2007 22:37:02 +0200 From: [EMAIL PROTECTED] Antonio Gallardo skrev: Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. For those not remembering, we are waiting for Joerg to retract his veto against switching to Java 1.5. In the meantime the benefit of supporting Java 1.4 decreases each day while the cost of doing so increases ... /Daniel Well, for what it's worth (which isn't much) I for one am glad Cocoon 2.2 still supports JDK 1.4. It's finally looking like our US datacentre is getting their act together so my team can plan to migrate our sites off Websphere 5.0 (JDK 1.3, and end-of-life'd about 9 months ago!) onto a more recent version. However, the new version that they are willing to support is 6.0, which uses... JDK 1.4 In 2007 the company decided to upgrade to websphere 6.0. It is a product from 2004. Hence I don't believe such cutting-edge technology as cocoon 2.2 is going to be picked up there until it is not 3 years old or so, hence we are talking about year 2010 when the company will plan to move to java 5 and cocoon 2.2. Is this correct? If yes, there is another reason to move to java 5 for cocoon 2.2 now! :) We're already being pressured to ditch Cocoon in favour of a proprietary in-house framework (which would be a shame IMO as Cocoon is a much better fit with our XML-based content management system). Without 1.4 support, Cocoon becomes a dead end for us with no upgrade path, which would make it harder to justify continuing with it. Minimal cocoon 2.1 requires java 1.3, but in fact you get more of it with java 1.4, some newer blocks requieres it as the minimal entry java version. Best Regards, Antonio Gallardo. I guess that makes us the few souls living in solitude :-) Andrew.
Re: trunk broken?
Grzegorz Kossakowski escribió: Let me guess, you use Java 1.4? In Java 1.4 ThreadLocal does not have remove() method and that's why the build fails. I have no idea how to fix it, though. Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Best Regards, Antonio Gallardo.
Re: trunk broken?
Grzegorz Kossakowski escribió: Antonio Gallardo pisze: Grzegorz Kossakowski escribió: Am I missing something, but IIRC cocoon 2.2. should compile and run with java 1.4. Is this correct? Yes, even though it seems that only few souls living in solitude use Java 1.4 these days... Not my case, I am already on 1.6. ;) I asked due the contract with our user base. Perhaps it is time to reconsider this issue before the 2.2 release. Best Regards, Antonio Gallardo.
Website: Outdated info: How to get listed in live sites link
Hi, The follow instructions still points to the our old bugzilla tracking system: http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed Best Regards, Antonio Gallardo.
Cocoon demo does not work.
http://cocoon.zones.apache.org/demos/21branch/ Best Regards, Antonio Gallardo
[jira] Commented: (COCOON-2040) Union widget does not work with booleanfield set as case widget
[ https://issues.apache.org/jira/browse/COCOON-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487434 ] Antonio Gallardo commented on COCOON-2040: -- Is not possible to resume the whole patch to this change in JXMacrosHelper.java: from: String value = (String)unionWidget.getValue(); to: String value = unionWidget.getValue(); Is there a test case to check it? Union widget does not work with booleanfield set as case widget --- Key: COCOON-2040 URL: https://issues.apache.org/jira/browse/COCOON-2040 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: cocoon-forms-impl-union.patch Union widget compares values without performing conversion. Booleanfield returns Boolean object, so result of comparison is always false. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Move CachingSource to cocoon-core
Reinhard Poetz escribió: Because of dependencies on the event-cache block, the caching source was added to the repository block when it moved out from scratchpad. After some refactorings I should be able now to move it to cocoon-core without having to add any new depenendencies there. As a caching source is of general interest for many of our users (see several requests on the users list) I want to propose to move it to cocoon-core. +1 Best Regards, Antonio Gallardo.
Re: [vote] Make status code attribute of seriailzers expandable
Reinhard Poetz escribió: I propose making the status code attribute of serializers expandable. This makes it easier to provide REST style services with Cocoon that make use of the different meanings of status codes. +1 Best Regards, Antonio Gallardo.
