[jira] Commented: (COCOON-1437) Htmlarea lost contents
[
http://issues.apache.org/jira/browse/COCOON-1437?page=comments#action_12439406
]
Jean-Baptiste Quenot commented on COCOON-1437:
--
Mistake, please read: There must be a conflict somewhere in the form onsubmit
handlers.
Htmlarea lost contents
--
Key: COCOON-1437
URL: http://issues.apache.org/jira/browse/COCOON-1437
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.2-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: Gioni Gennai
Assigned To: Cocoon Developers Team
In my project I use htmlarea with cform. I customize the html area calling a
js
function with onload event
body onload=initHtmlArea('descrizione'); return true;
function initHtmlArea(elementId) {
// inititalize editor
editor = new HTMLArea(elementId);
// retrive the config object
var config = editor.config;
// do custom configuration
config.toolbar = [
[
bold, italic, underline, separator,
undo, redo, separator,
justifyleft, justifycenter, justifyright, separator,
insertorderedlist, insertunorderedlist, outdent,
indent
]
]; HTMLArea.replace(elementId, config);
}
Where descrizione is the htmlarea's id
ft:widget id=descrizione
fi:styling type=textarea rows=20 style=width:100%/
/ft:widget
All seems to work, I have my htmlarea show in the form.
The problem is that in the form I have a selection list, with the
fi:styling
submit-on-change=true/, that I use to populate another selection list on
the
form. When i change the selection, in the first selection list, the second is
populate as I expect, but the text present in the htmlarea is lost.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1775) LdapTransformer: LDAP attributes may not contain ;
[ http://issues.apache.org/jira/browse/COCOON-1775?page=all ] Jean-Baptiste Quenot closed COCOON-1775. Resolution: Won't Fix Please reopen the issue if you can come up with a patch. Thanks! LdapTransformer: LDAP attributes may not contain ; Key: COCOON-1775 URL: http://issues.apache.org/jira/browse/COCOON-1775 Project: Cocoon Issue Type: Bug Components: Blocks: Naming Affects Versions: 2.1.8 Reporter: Antonio Fiol I found a case where the LDAP attribute name is: description;lang-en LDAPTransformer tries to create an element such as: ldap:description;lang-ensomething/ldap:description;lang-en This is not valid XML and causes an exception. In fact, this attribute naming scheme complies both with RFC 2596 [1] and RFC 2252 [2], so the behaviour of LDAPTransformer is somehow wrong. Three possible approaches: - Investigate further on the meaning of name;something other than name;lang-something and try to map that into meaningful XML attributes. e.g. description;lang-en -- ldap:description xml:lang=en - Split the attribute name at the first ; and put the rest as an attribute. For example, the attribute could be called attrs. e.g. description;lang-en -- ldap:description attrs=lang-en - Remove the ; character or change it into something else. e.g. description;lang-en -- ldap:description_lang-en IMHO the third approach is the worst because it defeats the LDAP purpose of ; which is to specify a characteristic of what is specified before. And I don't have a strong opinion whether the first approach is better than the second or vice-versa. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [CFORMS] Template priority problems fix with saxon
On 02.10.2006 15:05, [EMAIL PROTECTED] wrote: One of the patches was a change of template priorities in the forms-field-styling.xslt If this isn't applied, I get Abiguous Template errors from Saxon. xsl:template match=fi:styling/@* mode=styling Has to be changed to: xsl:template match=fi:styling/@* mode=styling priority=-1 And this bug is resolved. I would not call this a bug, it's just another way of confirming to the spec. It says [1]: It is an error if this leaves more than one matching template rule. An XSLT processor may signal the error; if it does not signal the error, it must recover by choosing, from amongst the matching template rules that are left, the one that occurs last in the stylesheet. But I don't like influencing the priority as it might break other stylesheets extending our ones. Not only once, but regularly. This can happen if we add a new template rule and have to adapt priority again. But probably this is not that much a matter anymore as there are already so many @priority's added. I only wonder with which template it conflicts. All others have specified the attribute name and should so be more specific. Does this occur only with a specific version of Saxon? Is everybody using Saxon in need for such a patch? Jörg [1] http://www.w3.org/TR/xslt#conflict
[jira] Closed: (COCOON-1774) Fine Tuning Ajax Handling in CForms
[ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Ajax Affects Versions: 2.1.8 Reporter: Eric Meyer Assigned To: Antonio Gallardo Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with fi:styling ajax='false' /, and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1714) repeater min-size does not prevent removal of rows below minium size
[ http://issues.apache.org/jira/browse/COCOON-1714?page=all ] Jean-Baptiste Quenot closed COCOON-1714. Resolution: Won't Fix Please reopen the issue if you can come up with a patch. Thanks! repeater min-size does not prevent removal of rows below minium size Key: COCOON-1714 URL: http://issues.apache.org/jira/browse/COCOON-1714 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Eric Meyer repeater min-size does not prevent removal of rows below minium size e.g. fd:repeater id=industryStructure initial-size=1 min-size=1 I can remove all the rows and submit. Shouldn't min-size keep it from ever having fewer than those rows, or does this only cause a validation error. If the latter, then how is this error displayed? Regards, Eric -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1682) Custom headers for Sendmail Action/Logicsheet/Transformer needed
[ http://issues.apache.org/jira/browse/COCOON-1682?page=all ] Jean-Baptiste Quenot closed COCOON-1682. Resolution: Won't Fix Please reopen the issue if you can come up with a patch. Thanks! Custom headers for Sendmail Action/Logicsheet/Transformer needed Key: COCOON-1682 URL: http://issues.apache.org/jira/browse/COCOON-1682 Project: Cocoon Issue Type: Wish Components: Blocks: Mail Affects Versions: 2.1.7 Reporter: Lauri Pitkänen Priority: Minor Possibility to add multiple custom headers to messages from Sendmail Action/Logicsheet/Transformer would eliminate the need for adding missing fixed optional headers like ReplyTo one by one. This is something that is already available in the AxKit XSP tag library:: http://search.cpan.org/~kjetilk/AxKit-XSP-Sendmail/Sendmail.pm#%3Csendmail:header%3E Configuration example: sendmail:header name=Precedencebulk/sendmail:header sendmail:header name=X-My-HeaderSomething/sendmail:header Headers in the message: Precedence: bulk X-My-Header: Something -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1655) JavaFlow/CForm/select-list crash
[
http://issues.apache.org/jira/browse/COCOON-1655?page=comments#action_12439412
]
Jean-Baptiste Quenot commented on COCOON-1655:
--
Simone, I think the patch can be applied. Or if it is not relevant anymore, we
may close the issue.
JavaFlow/CForm/select-list crash
Key: COCOON-1655
URL: http://issues.apache.org/jira/browse/COCOON-1655
Project: Cocoon
Issue Type: Bug
Components: Blocks: Java Flow
Affects Versions: 2.1.7
Environment: Operating System: other
Platform: Other
Reporter: Benoit Deshaies
Assigned To: Cocoon Developers Team
Attachments: javaflow-continuationstack.diff
I get an error whenever I include an fd:selection-list src=cocoon:/XYZ
where
both the form and the XYZ pipeline use JavaFlow. The error is:
No continuation is running
cause: java.lang.IllegalStateException: No continuation is running
java.lang.IllegalStateException: No continuation is running
at
org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
at
org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
at
org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
The reason is that when cocoon:/XYZ runs, a continuation is created for the
same
thread as the form continuation. The continuationsmap in Continuation class
gets
overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
leaving no continuation for the form.
Here's a bit of code from the app to help explain.
The form contains a selection list defined as:
fd:field id=user
fd:datatype base=string/
fd:selection-list src=cocoon:/UserSelectList dynamic=true/
/fd:field
The sitemap contains:
map:match pattern=UserSelectList
map:call function=generateUserList/
/map:match
Then I have the following JavaFlow
public void doGenerateUserList() throws Exception {
Collection userList = databaseManager.getUserList();
sendPage(user_list, new VarMap().add(list, userList) );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1924) [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later
[ http://issues.apache.org/jira/browse/COCOON-1924?page=all ] Jean-Baptiste Quenot closed COCOON-1924. Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Committed revision 452332, thanks! [PATCH] cocoon-fop-ng-block introduces support for FOP 0.92beta and later - Key: COCOON-1924 URL: http://issues.apache.org/jira/browse/COCOON-1924 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Assigned To: Jean-Baptiste Quenot Fix For: 2.2-dev (Current SVN) Attachments: cocoon-fop-ng-block.patch, fop1, xmlgraphics-maven-repo.tar.gz This patch was written by Jeremias Märki (FOP Developer) and Lars Trieloff. It uses the new FOP API which simplifies the Serializer code greatly and allows for relative addressing of resources using the URIResolver framework. This patch should close COCOON-1797, COCOON-1795 and COCOON-531 It depends on the addition of the FOP pom to the central repository which is in the works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1437) Htmlarea lost contents
[
http://issues.apache.org/jira/browse/COCOON-1437?page=comments#action_12439404
]
Jean-Baptiste Quenot commented on COCOON-1437:
--
This is a known issue: when using HTMLArea in a form, you can't use Cocoon
Forms submit-on-change or fd:submit. There must be a conflict somewhere in
the body onload handlers. As a workaround you can use input type=submit
insteadfd:submit of ft:widget.
Htmlarea lost contents
--
Key: COCOON-1437
URL: http://issues.apache.org/jira/browse/COCOON-1437
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.2-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: Gioni Gennai
Assigned To: Cocoon Developers Team
In my project I use htmlarea with cform. I customize the html area calling a
js
function with onload event
body onload=initHtmlArea('descrizione'); return true;
function initHtmlArea(elementId) {
// inititalize editor
editor = new HTMLArea(elementId);
// retrive the config object
var config = editor.config;
// do custom configuration
config.toolbar = [
[
bold, italic, underline, separator,
undo, redo, separator,
justifyleft, justifycenter, justifyright, separator,
insertorderedlist, insertunorderedlist, outdent,
indent
]
]; HTMLArea.replace(elementId, config);
}
Where descrizione is the htmlarea's id
ft:widget id=descrizione
fi:styling type=textarea rows=20 style=width:100%/
/ft:widget
All seems to work, I have my htmlarea show in the form.
The problem is that in the form I have a selection list, with the
fi:styling
submit-on-change=true/, that I use to populate another selection list on
the
form. When i change the selection, in the first selection list, the second is
populate as I expect, but the text present in the htmlarea is lost.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1316) I18NTransformer Cannot format ISO8601 dateTime format
[ http://issues.apache.org/jira/browse/COCOON-1316?page=all ] Jean-Baptiste Quenot closed COCOON-1316. Resolution: Won't Fix I18nTransformer is using SimpleDateFormat, and it is not compatible with ISO 8601. Have a look at COCOON-1648 I18NTransformer Cannot format ISO8601 dateTime format - Key: COCOON-1316 URL: http://issues.apache.org/jira/browse/COCOON-1316 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.5 Environment: Operating System: All Platform: All Reporter: Dean Cording Assigned To: Cocoon Developers Team The i18nTransformer cannot format datesTime elements using the ISO8601 format of CCYY-MM_DDThh:mm:ss as the source (Note the 'T' is the letter T and not a field). An example date time is: 2002-04-02T12:30:00.00+10:00 A src-pattern could be used but the transformer barfs on the 'T' with java.lang.IllegalArgumentException: Illegal pattern character 'T'. ISO8601 is the date/time format specified for dateTime elements in the XML Schema definition and is the dateTime format returned by many XML databases. For more information see: http://www.w3.org/TR/xmlschema-2/#dateTime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RT] User poll to find unused components
Hi all, Yesterday we had an interesting discussion at the hackathon about how to identify unused components so as to remove/deprecate them in order to cleanup the code base. We cannot consider the last commit date on a component as the measure of its usefulness, as many components are simply finished, i.e. just work and don't need more work, but are used daily by most users (e.g. the HTML serializer). So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution. WDYT? Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON-1437) Htmlarea lost contents
[
http://issues.apache.org/jira/browse/COCOON-1437?page=comments#action_12439413
]
Jeroen Reijn commented on COCOON-1437:
--
I've fixed this before inside our cocoon based CMS. I will have to see if it
still applies for cocoon-2.1.10. I can submit a patch otherwise.
Htmlarea lost contents
--
Key: COCOON-1437
URL: http://issues.apache.org/jira/browse/COCOON-1437
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.2-dev (Current SVN)
Environment: Operating System: All
Platform: All
Reporter: Gioni Gennai
Assigned To: Cocoon Developers Team
In my project I use htmlarea with cform. I customize the html area calling a
js
function with onload event
body onload=initHtmlArea('descrizione'); return true;
function initHtmlArea(elementId) {
// inititalize editor
editor = new HTMLArea(elementId);
// retrive the config object
var config = editor.config;
// do custom configuration
config.toolbar = [
[
bold, italic, underline, separator,
undo, redo, separator,
justifyleft, justifycenter, justifyright, separator,
insertorderedlist, insertunorderedlist, outdent,
indent
]
]; HTMLArea.replace(elementId, config);
}
Where descrizione is the htmlarea's id
ft:widget id=descrizione
fi:styling type=textarea rows=20 style=width:100%/
/ft:widget
All seems to work, I have my htmlarea show in the form.
The problem is that in the form I have a selection list, with the
fi:styling
submit-on-change=true/, that I use to populate another selection list on
the
form. When i change the selection, in the first selection list, the second is
populate as I expect, but the text present in the htmlarea is lost.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Simplify flow usage
I now implemented this convention stuff - all files located in the flow directory relative to the current sitemap are added to the flow interpreter - regardless of the file name suffix and the used interpreter (javascript, javaflow etc). The directory is of course optional. By this we show a best practice of how to use flow - if for any reason the user wants to use a different location, it's possible by specifying the location attribute on the flow node. I think we should leave the other convention directories for spring and avalon configurations and the properties inside the config directory for now. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] User poll to find unused components
Sylvain Wallez wrote: Hi all, Yesterday we had an interesting discussion at the hackathon about how to identify unused components so as to remove/deprecate them in order to cleanup the code base. We cannot consider the last commit date on a component as the measure of its usefulness, as many components are simply finished, i.e. just work and don't need more work, but are used daily by most users (e.g. the HTML serializer). So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution. WDYT? +1 .. anything that stays should be released in 2.2 ASAP. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Indexing In Lucene
Hi, Canyou tell me how indexing takes place in lucene(Depth).if document has 1n indices then which algorithm it uses,which information retrival model it uses Thanks Regards, Akil Ajani Cognizant Technology Solutions India Pvt. Ltd. Plot # 26, Rajiv Gandhi Infotech Park, MIDC Hinjewadi, Pune 411057 Tel: (91) (20) 40201100 ext 2825 Vnet: 22809 Technical Skill is the mastery of complexity, while creativity is the mastery of simplicity. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
[jira] Closed: (COCOON-1908) Add query support to JCR source factory
[ http://issues.apache.org/jira/browse/COCOON-1908?page=all ] Lars Trieloff closed COCOON-1908. - Resolution: Later This will be included in the reworked JCR sourcefactory that Mindquarry is currently working on. Add query support to JCR source factory --- Key: COCOON-1908 URL: http://issues.apache.org/jira/browse/COCOON-1908 Project: Cocoon Issue Type: New Feature Components: Blocks: JCR Affects Versions: 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: cocoon-jcr-add-query-support.patch The current implementation of the JCRSourceFactory is missing the support for JCR queries (XPath and SQL) and only allows direct paths (like jcr://root/folder/file). I have implemented a simple query handling (see patch). It supports both XPath (required for JCR Level 1 compliance, thus any JCR implementation) and SQL (optional JCR feature). The query strings given as Source-URIs must look like this: XPath: jcr://xpath!//root/* (which maps to the xpath query //root/* which is passed on to the JCR Query) jcr://!//root/* (which is just a shorthand notation for the above, using Xpath) SQL: jcr://sql!select * from nt:base where jcr:path = '/root/myfile' (well, which maps to the sql query select * from nt:base where jcr:path = '/root/myfile') There is a restriction for the queries: the result to be returned must be a content-node with no children and some streamable content. The JCRNodeSource class does not allow collections to be returned. I am working on subclasses that will target this issue (using the XMLizable interface) but this is not yet finished. I tried to make the patch complete, including updated javadocs for the JCRSourceFactory class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1279) caching point pipelines and smart caching
[ http://issues.apache.org/jira/browse/COCOON-1279?page=all ] Jean-Baptiste Quenot closed COCOON-1279. Fix Version/s: 2.2-dev (Current SVN) 2.1.9 Resolution: Fixed Done in trunk as well: Committed revision 452380. caching point pipelines and smart caching - Key: COCOON-1279 URL: http://issues.apache.org/jira/browse/COCOON-1279 Project: Cocoon Issue Type: Improvement Components: - Components: Avalon Affects Versions: 2.1.5 Environment: Operating System: Linux Platform: PC Reporter: Oliver Powell Assigned To: Jean-Baptiste Quenot Priority: Minor Fix For: 2.2-dev (Current SVN), 2.1.9 I think if you choose to use caching-point type caching, then smart-caching should effectively be automatically turned off. Or, in other words, I would expect when using the caching-point pipeline processor that it would by default behave as it does when smart-caching is off: which is to always look for shorter keys in the cache if a response is not found for the current key combination. Perhaps this could be implemented by having CachingPointProcessingPipeline override the validatePipeline method to make it always try shorter keys (at the same time, remove this functionality from the AbstractCachingProcessingPipeline). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1905) [PATCH] Support non-file resources for jaas.config in JCR block
[ http://issues.apache.org/jira/browse/COCOON-1905?page=all ] Lars Trieloff closed COCOON-1905. - Resolution: Later This will be included in the reworked JCR sourcefactory that Mindquarry is currently working on. [PATCH] Support non-file resources for jaas.config in JCR block --- Key: COCOON-1905 URL: http://issues.apache.org/jira/browse/COCOON-1905 Project: Cocoon Issue Type: Improvement Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Priority: Minor Attachments: cocoon-jcr-jaas-uri-source.patch The current implementation of the JCR-block requires the user to define a physical file as source for the jaas.config. While is behaviour matches the requirements of the Java JAAS implementation it is inconvenient for development and prevents the creation of a generic out-of-the-box cocoon-JCR-example. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1799) [PATCH] Threads waste when reading a not found resource.
[
http://issues.apache.org/jira/browse/COCOON-1799?page=comments#action_12439432
]
Jean-Baptiste Quenot commented on COCOON-1799:
--
Done in trunk as well:
Committed revision 452380.
[PATCH] Threads waste when reading a not found resource.
Key: COCOON-1799
URL: http://issues.apache.org/jira/browse/COCOON-1799
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Simone Gianni
Assigned To: Antonio Gallardo
Priority: Blocker
Fix For: 2.1.9
Attachments: pipeline.diff
When setting up a pipeline with a reader on a not found file, the first time
a 404 is reported, but following requests will hang up and the thread will
never get released, causing a potential complete lock exausting threads.
In the AbstractCachingProcessingPipeline class, in ProcessReader method, the
following happens :
- 774: a pcKey is created for caching content
- 853: the method eventually waits if another thread is generating
- 869: the method acquires a lock, to avoid other threads to generate twice
- 886: if there is no need cache validity pcKey is setted to null
- 918: if an exception occurrs while generating, the following code is in a
finally :
if (pcKey != null) {
releaseLock(pcKey);
}
This obviously brings to the following situation :
- A non existing resource is being generated
- A lock is acquired
- The FileSource returns null if the file does not exist.
- So pcKey is setted to null.
- An exception is thrown, since the file is not found.
- The finally block does not release the lock
- Next requests on the same file will hang waiting on the lock, but the other
thread will never release it.
This can easily consume all threads, it's quite easy to have this kind of
errors on a missing gif, or css, or favicon.ico or something else.
I modified this class so that it :
- Does not set pckey to null when readerValidity == null
- Checks for pckey != null readerValidity != null on line 907 so that
content is not cached if readerValidity == null
- Since pckey is != null the lock is released.
I tested it and seems to work correctly, but this is core stuff, please
double check it!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1926) CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException
CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException - Key: COCOON-1926 URL: http://issues.apache.org/jira/browse/COCOON-1926 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Following stack trace: java.lang.NullPointerException at org.apache.cocoon.environment.ObjectModelHelper.getRequest(ObjectModelHelper.java:65) at org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:400) at org.apache.cocoon.ProcessingUtil.getSitemapServiceManager(ProcessingUtil.java:110) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:154) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550) at org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258) at org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349) at $Proxy1.startElement(Unknown Source) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.startNode(DOMStreamer.java:435) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.stream(DOMStreamer.java:217) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:141) at org.apache.cocoon.SitemapComponentTestCase.transform(SitemapComponentTestCase.java:404) at org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1(CIncludeTransformerTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] User poll to find unused components
On 10/3/06, Sylvain Wallez [EMAIL PROTECTED] wrote: ...So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution... +1 on the idea, a first step might be to do this for blocks before going down to the level of components. -Bertrand
Re: [RT] User poll to find unused components
Bertrand Delacretaz said the following on 3/10/06 12:05: On 10/3/06, Sylvain Wallez [EMAIL PROTECTED] wrote: ...So the idea is to involve users in the process and conduct a poll where they will be able to list the components they use regularly so that we can find those that can be pushed to end-of-life and utimately removed from the distribution... +1 on the idea, a first step might be to do this for blocks before going down to the level of components. +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. Bye, Helma
[jira] Updated: (COCOON-1900) BUG in forms-field-styling.xsl
[ http://issues.apache.org/jira/browse/COCOON-1900?page=all ]
Gabriele Columbro updated COCOON-1900:
--
Attachment: forms-field-styling.diff
Patch for the trunk for adding the input name.
BUG in forms-field-styling.xsl
--
Key: COCOON-1900
URL: http://issues.apache.org/jira/browse/COCOON-1900
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Reporter: johnson hsu
Attachments: forms-field-styling.diff
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
must add a name attribute.
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED] name=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
Without the name attribute, It's not convenient to find the value of checkbox
by script.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1900) BUG in forms-field-styling.xsl
[
http://issues.apache.org/jira/browse/COCOON-1900?page=comments#action_12439440
]
Gabriele Columbro commented on COCOON-1900:
---
Patch must be applied to resolve the issue (IMHO it's worth)
BUG in forms-field-styling.xsl
--
Key: COCOON-1900
URL: http://issues.apache.org/jira/browse/COCOON-1900
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Reporter: johnson hsu
Attachments: forms-field-styling.diff
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
must add a name attribute.
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED] name=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
Without the name attribute, It's not convenient to find the value of checkbox
by script.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Dependency on cocoon-license
Currently cocoon-core depends on cocoon-license. Do we really need this
dependency. From a legal POV I'd say no. Only the all-in-one assembly Vadim is
workin on, needs to have the licenses included.
WDOT?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
RE: [RT] User poll to find unused components
+1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. How about letting users classifying blocks as used: a) always, b) often (most of the time), c) rarely (only once or twice)? (and asking them how many webapps they have build using Cocoon) Sounds more informative to me than a top 5.. Kind regards, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
[jira] Assigned: (COCOON-1196) [XSP] logicsheet-util.xsl failes with duplicate namespace declarations
[ http://issues.apache.org/jira/browse/COCOON-1196?page=all ] Jörg Heinicke reassigned COCOON-1196: - Assignee: Jörg Heinicke (was: Cocoon Developers Team) [XSP] logicsheet-util.xsl failes with duplicate namespace declarations -- Key: COCOON-1196 URL: http://issues.apache.org/jira/browse/COCOON-1196 Project: Cocoon Issue Type: Bug Components: Blocks: XSP Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Andreas Hartmann Assigned To: Jörg Heinicke Priority: Minor If an input module namespace is declared twice, e.g. xmlns:xsp-input=http://apache.org/cocoon/xsp/input/1.0; xmlns:input=http://apache.org/cocoon/xsp/input/1.0; and input:param is used for a required parameter: input:get-attribute input:param name=namefoo/input:param input:param name=modulelist/input:param /input:get-attribute a ProcessingException is thrown, because the template get-namespace-prefix in logicsheet-util.xsl is matching the first namespace declaration and does not find any parameter tags for this namespace prefix. I think it is not a good practise to rely on namespace prefixes. Wouldn't it be possible to use just the namespace URIs to resolve the parameter? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1180) OO samples don't work any longer
[ http://issues.apache.org/jira/browse/COCOON-1180?page=comments#action_12439454 ] Daniele Madama commented on COCOON-1180: I tested it with 2.1.10-dev and current 2.2 trunk on MacOSX and NeoOffice2.0b3 and all the cases (four) works perfectly. I think that this bug can be closed. OO samples don't work any longer Key: COCOON-1180 URL: http://issues.apache.org/jira/browse/COCOON-1180 Project: Cocoon Issue Type: Bug Components: - Samples Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assigned To: Cocoon Developers Team Attachments: hello.sxc, hello.sxw http://127.0.0.1:/samples/hello-world/hello.sxw (writer) http://127.0.0.1:/samples/hello-world/hello.sxc (calc) both crash my OO 1.1.1 while http://127.0.0.1:/samples/hello-world/hello.sxi (impress) http://127.0.0.1:/samples/hello-world/hello.sxd (draw) still work. Stephan Meinl mentions at http://marc.theaimsgroup.com/?t=10868122679r=1w=4 that there is a different behaviour with the older Xalan 2.5.2 (i.e. it works) instead of 2.6.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] User poll to find unused components
Geert Josten wrote: +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. How about letting users classifying blocks as used: a) always, b) often (most of the time), c) rarely (only once or twice)? (and asking them how many webapps they have build using Cocoon) Sounds more informative to me than a top 5.. Sure. Defining the top 10 or top 5 is then the result of aggregating and compiling all information provided by users. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] User poll to find unused components
Sylvain Wallez said the following on 3/10/06 13:26: Geert Josten wrote: +1 for the blocks, because it simplifies the stay/leave selection. In a later stage the poll can be repeated per block for the individual components. I also suggest to ask for a TOP 5 and create a TOP 10 from that to cater to a larger population. How about letting users classifying blocks as used: a) always, b) often (most of the time), c) rarely (only once or twice)? (and asking them how many webapps they have build using Cocoon) Sounds more informative to me than a top 5.. Sure. Defining the top 10 or top 5 is then the result of aggregating and compiling all information provided by users. First off: I definitely agree that more information gives a more informative choice. However, it's no problem to ask a lot of information of the users, but we have to make the process quick and easy. Defining a top 5 of your favorite blocks is a quick response to a mail. Walking through a list of predefined blocks and adding a, b, or c takes more time and I do hope that people will take the time to walk through them. If we want the abc options, we need to carefully construct the poll to avoid putting off people. Bye, Helma
[jira] Assigned: (COCOON-1462) NullPointerException in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1462?page=all ] Vadim Gritsenko reassigned COCOON-1462: --- Assignee: Vadim Gritsenko (was: Cocoon Developers Team) NullPointerException in SQLTransformer -- Key: COCOON-1462 URL: http://issues.apache.org/jira/browse/COCOON-1462 Project: Cocoon Issue Type: Bug Components: Blocks: Databases Affects Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Brad Assigned To: Vadim Gritsenko Attachments: cocoon.patch, cocoon_patch In src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java around line 1134 are the lines Clob clob = rs.getClob(i); InputStream inputStream = clob.getAsciiStream(); which cause a NPE when getClob() returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dependency on cocoon-license
Reinhard Poetz wrote: Currently cocoon-core depends on cocoon-license. Do we really need this dependency. From a legal POV I'd say no. Only the all-in-one assembly Vadim is workin on, needs to have the licenses included. I agree that this dependency is required for downloadable release. I'm not sure what are the requirements for jar files released into the maven repository, though. Vadim
[jira] Closed: (COCOON-1462) NullPointerException in SQLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1462?page=all ] Vadim Gritsenko closed COCOON-1462. --- Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed incorporated into current code NullPointerException in SQLTransformer -- Key: COCOON-1462 URL: http://issues.apache.org/jira/browse/COCOON-1462 Project: Cocoon Issue Type: Bug Components: Blocks: Databases Affects Versions: 2.1.8 Environment: Operating System: All Platform: All Reporter: Brad Assigned To: Vadim Gritsenko Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) Attachments: cocoon.patch, cocoon_patch In src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java around line 1134 are the lines Clob clob = rs.getClob(i); InputStream inputStream = clob.getAsciiStream(); which cause a NPE when getClob() returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1926) CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException
[ http://issues.apache.org/jira/browse/COCOON-1926?page=all ] Lars Trieloff updated COCOON-1926: -- Attachment: cocoon-core-testcases.patch This patch changes the sitemaptestcase class to be able to resolve beans as if it were running in a servlet container. The result is that all test cases in cocoon-core are working again. CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException - Key: COCOON-1926 URL: http://issues.apache.org/jira/browse/COCOON-1926 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Attachments: cocoon-core-testcases.patch Following stack trace: java.lang.NullPointerException at org.apache.cocoon.environment.ObjectModelHelper.getRequest(ObjectModelHelper.java:65) at org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:400) at org.apache.cocoon.ProcessingUtil.getSitemapServiceManager(ProcessingUtil.java:110) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:154) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550) at org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258) at org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349) at $Proxy1.startElement(Unknown Source) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.startNode(DOMStreamer.java:435) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.stream(DOMStreamer.java:217) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:141) at org.apache.cocoon.SitemapComponentTestCase.transform(SitemapComponentTestCase.java:404) at org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1(CIncludeTransformerTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dependency on cocoon-license
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Currently cocoon-core depends on cocoon-license. Do we really need
this dependency. From a legal POV I'd say no. Only the all-in-one
assembly Vadim is workin on, needs to have the licenses included.
I agree that this dependency is required for downloadable release. I'm
not sure what are the requirements for jar files released into the maven
repository, though.
We have to provide LICENSE.txt and NOTICE.txt at the root level of each jar file
that we release. That's all.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
[VOTE] Lars Trieloff as a new Cocoon committer
Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) I know Lars since nearly 5 years as we were both contributing to the Docbook stuff. He is very professionnal and works in IT since the age of 20. He also wrote the online Docbook tool which allows to post a Docbook document and get the PDF in return, and he is the author of a Docbook book in German! And his current involvement into Cocoon 2.2 shows that he is already kind of committed to Cocoon, and since a few months he submitted very valuable patches. So please cast your votes! -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) snip/ So please cast your votes! +1 But Lars will have to pay a beer to all people voting +1... or drink a beer for each of them :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [VOTE] Lars Trieloff as a new Cocoon committer
+1 -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
[jira] Closed: (COCOON-1926) CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException
[ http://issues.apache.org/jira/browse/COCOON-1926?page=all ] Carsten Ziegeler closed COCOON-1926. Fix Version/s: 2.2-dev (Current SVN) Resolution: Fixed Patch applied. Thanks! Please cross-check CIncludeTransformerTestCase.testCInclude1 fails with NullPointerException - Key: COCOON-1926 URL: http://issues.apache.org/jira/browse/COCOON-1926 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Lars Trieloff Fix For: 2.2-dev (Current SVN) Attachments: cocoon-core-testcases.patch Following stack trace: java.lang.NullPointerException at org.apache.cocoon.environment.ObjectModelHelper.getRequest(ObjectModelHelper.java:65) at org.apache.cocoon.environment.internal.EnvironmentHelper.getSitemapServiceManager(EnvironmentHelper.java:400) at org.apache.cocoon.ProcessingUtil.getSitemapServiceManager(ProcessingUtil.java:110) at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:154) at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:550) at org.apache.cocoon.transformation.CIncludeTransformer.startTransformingElement(CIncludeTransformer.java:258) at org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(AbstractSAXTransformer.java:460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349) at $Proxy1.startElement(Unknown Source) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.startNode(DOMStreamer.java:435) at org.apache.cocoon.xml.dom.DOMStreamer$NamespaceNormalizingDOMStreamer.stream(DOMStreamer.java:217) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:141) at org.apache.cocoon.SitemapComponentTestCase.transform(SitemapComponentTestCase.java:404) at org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1(CIncludeTransformerTestCase.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-574) [PATCH] fixed redirect under JRun 3.1
[ http://issues.apache.org/jira/browse/COCOON-574?page=all ] Vadim Gritsenko updated COCOON-574: --- Bugzilla Id: (was: 16537) Affects Version/s: 2.1.10-dev (current SVN) [PATCH] fixed redirect under JRun 3.1 - Key: COCOON-574 URL: http://issues.apache.org/jira/browse/COCOON-574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.0.5-dev (Current CVS), 2.1.10-dev (current SVN) Environment: Operating System: All Platform: All Reporter: Michal Durdina Assigned To: Cocoon Developers Team Attachments: HttpEnvironment.java.diff, release_2_1_5_1.patch_3.txt Proposed WebSphere 4.0/4.0.1 response.encodeRedirectURL() bug fix (by VG) doesn't work for JRun 3.1. It produces double base path fragment on the resulting URL, when it mistakenly assumes WS bug. I.e. for redirect to ../myfile.html at http://host/webapp/mydir/main.html; the result is http://host/webapp/mydir/webapp/mydir/../myfile.html; on JRun. The patch adds additional check for output from encodeRedirectURL() and ONLY IF it actually does not contain expected base path, it adds one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 03.10.2006 15:01, Jean-Baptiste Quenot wrote: I think time has come for Lars Trieloff to become a Cocoon committer +1 Jörg
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 03 Oct 2006, at 15:04, Sylvain Wallez wrote: But Lars will have to pay a beer to all people voting +1... or drink a beer for each of them :-) or do both :-P +1, welcome Lars! Jorg
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 10/3/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: ...So please cast your votes!.. +1, getting to know Lars at the GT has been a pleasure, and the quality of his patches (not to mention his extensive background in the Docbook world) make this an easy vote for me. -Bertrand
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 10/3/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, +1 -- Peter Hunsberger
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) I know Lars since nearly 5 years as we were both contributing to the Docbook stuff. He is very professionnal and works in IT since the age of 20. He also wrote the online Docbook tool which allows to post a Docbook document and get the PDF in return, and he is the author of a Docbook book in German! And his current involvement into Cocoon 2.2 shows that he is already kind of committed to Cocoon, and since a few months he submitted very valuable patches. So please cast your votes! +1 Vadim
[jira] Assigned: (COCOON-1900) BUG in forms-field-styling.xsl
[ http://issues.apache.org/jira/browse/COCOON-1900?page=all ]
Jörg Heinicke reassigned COCOON-1900:
-
Assignee: Jörg Heinicke
BUG in forms-field-styling.xsl
--
Key: COCOON-1900
URL: http://issues.apache.org/jira/browse/COCOON-1900
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Reporter: johnson hsu
Assigned To: Jörg Heinicke
Attachments: forms-field-styling.diff
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
must add a name attribute.
xsl:template match=fi:[EMAIL PROTECTED]'output' or
fi:styling/@type='output'] priority=3
input id=[EMAIL PROTECTED] type=checkbox title={fi:hint}
disabled=disabled
value=[EMAIL PROTECTED] name=[EMAIL PROTECTED]
xsl:if test=fi:value != 'false'
xsl:attribute name=checkedchecked/xsl:attribute
/xsl:if
/input
/xsl:template
Without the name attribute, It's not convenient to find the value of checkbox
by script.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot skrev: I think time has come for Lars Trieloff to become a Cocoon committer +1 /Daniel
[jira] Created: (COCOON-1927) ehcache files in java.io.tmpdir
ehcache files in java.io.tmpdir --- Key: COCOON-1927 URL: http://issues.apache.org/jira/browse/COCOON-1927 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10-dev (current SVN) Reporter: Richard Frovarp Priority: Minor Running the demo Cocoon Jetty servlet results in the ehcache files being put into java.io.tmpdir instead of Jetty__xx___/cocoon-files/cache-dir. This change seemed to take place with the change to ehcache 1.2. Looking through the ehcache documentation, the constructor has changed, and if the old constructor is used, it will put the cache files in java.io.tmpdir, instead of the location specified. This also affects other projects using Cocoon, resulting in being able to run only one instance, without changing the java.io.tmpdir directory for each instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
+1 Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Closed: (COCOON-1242) XML serializer puts DOCTYPE after initial XML comments
[ http://issues.apache.org/jira/browse/COCOON-1242?page=all ] Jörg Heinicke closed COCOON-1242. - Resolution: Won't Fix This should be posted for the Xalan project - if it has not been fixed yet there. XML serializer puts DOCTYPE after initial XML comments -- Key: COCOON-1242 URL: http://issues.apache.org/jira/browse/COCOON-1242 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Emilian LOSNEANU Assigned To: Cocoon Developers Team Priority: Minor xml serializer places !DOCTYPE after the comment in the source file. Source: === !-- Comment -- html head/head /html Result: === ?xml version=1.0 encoding=UTF-8?!-- Comment --!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html head/head /html This is what I used in my sitemap.xmap file: map:serializers default=xhtml map:serializer logger=sitemap.serializer.xhtml mime-type=text/html name=xhtml src=org.apache.cocoon.serialization.XMLSerializer doctype-public-//W3C//DTD XHTML 1.1//EN/doctype-public doctype-systemhttp://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd/doctype-system encodingUTF-8/encoding /map:serializer /map:serializers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [VOTE] Lars Trieloff as a new Cocoon committer
I think time has come for Lars Trieloff to become a Cocoon committer, +1 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot wrote:
Dear Community,
I think time has come for Lars Trieloff to become a Cocoon
committer, so he'll be able to commit his numerous patches
himself, including the last hair-pulling cocoon-core tests fixes
today ;-)
I know Lars since nearly 5 years as we were both contributing to
the Docbook stuff. He is very professionnal and works in IT since
the age of 20. He also wrote the online Docbook tool which allows
to post a Docbook document and get the PDF in return, and he is
the author of a Docbook book in German!
And his current involvement into Cocoon 2.2 shows that he is
already kind of committed to Cocoon, and since a few months he
submitted very valuable patches.
So please cast your votes!
+1, welcome Lars!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Jean-Baptiste Quenot wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) I know Lars since nearly 5 years as we were both contributing to the Docbook stuff. He is very professionnal and works in IT since the age of 20. He also wrote the online Docbook tool which allows to post a Docbook document and get the PDF in return, and he is the author of a Docbook book in German! And his current involvement into Cocoon 2.2 shows that he is already kind of committed to Cocoon, and since a few months he submitted very valuable patches. So please cast your votes! +1, welcome -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [VOTE] Lars Trieloff as a new Cocoon committer
On 10/3/06, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, +1, bring the Heineken kegs! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[jira] Closed: (COCOON-1196) [XSP] logicsheet-util.xsl failes with duplicate namespace declarations
[ http://issues.apache.org/jira/browse/COCOON-1196?page=all ] Jörg Heinicke closed COCOON-1196. - Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Matching/Selecting is now done using namespace-uri instead of namespace-prefix found in an obscure way. The old way would not have been only failed with duplicate namespace declarations, but also for redeclared namespaces. [XSP] logicsheet-util.xsl failes with duplicate namespace declarations -- Key: COCOON-1196 URL: http://issues.apache.org/jira/browse/COCOON-1196 Project: Cocoon Issue Type: Bug Components: Blocks: XSP Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Andreas Hartmann Assigned To: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN) If an input module namespace is declared twice, e.g. xmlns:xsp-input=http://apache.org/cocoon/xsp/input/1.0; xmlns:input=http://apache.org/cocoon/xsp/input/1.0; and input:param is used for a required parameter: input:get-attribute input:param name=namefoo/input:param input:param name=modulelist/input:param /input:get-attribute a ProcessingException is thrown, because the template get-namespace-prefix in logicsheet-util.xsl is matching the first namespace declaration and does not find any parameter tags for this namespace prefix. I think it is not a good practise to rely on namespace prefixes. Wouldn't it be possible to use just the namespace URIs to resolve the parameter? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
Hi, Jean-Baptiste Quenot wrote: So please cast your votes! +1, welcome Lars! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
[jira] Updated: (COCOON-1867) BeanConvertor uses a WeakHashMap in the wrong way.
[ http://issues.apache.org/jira/browse/COCOON-1867?page=all ] Gabriele Columbro updated COCOON-1867: -- Attachment: BeanConvertor-1867.diff Changed WeakHashMap to org.apache.commons.collections.map.ReferenceMap BeanConvertor uses a WeakHashMap in the wrong way. -- Key: COCOON-1867 URL: http://issues.apache.org/jira/browse/COCOON-1867 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9, 2.1.10-dev (current SVN) Reporter: Simone Gianni Assigned To: Simone Gianni Priority: Critical Attachments: BeanConvertor-1867.diff In the BeanConvertor, when a bean is converted to a string, the bean is stored in a WeakHashMap this way : m_objects.put(idValue, value); Actually idValue is a string representing the bean (toString or evalued on id_path) while the value is the bean. WeakHashMap DOES NOT remove a mapping when the bean is garbage collected, but actually removes it when the KEY is garbage collected. This means that since the string is serialized to XML in the form instance and then dropped, the mapping could be removed even while the user is filling the form, with the conseguence that the convertor stops working, see a null value, reports a validation error, even if the user correctly filled the form. This is even worse when you are using a selection list of beans, because in that case the bean has no chanches to enter the m_objects map anymore, since the selection list has been generated and stored st the beginning of the form (maybe thru flow, or on-create) and is not asking the convertor to convert the beans anymore. A better solution (and IMMO what the author intended to do) is to remove the mapping (so that the map does not hold references for everything) when the BEAN gets garbage collected. In this case I'm experimenting with apache commons ReferenceMap, which actually can remove mappings when the value (bean) is garbage collected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [VOTE] Lars Trieloff as a new Cocoon committer
So please cast your votes! -- +1, welcome! -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Great GT!
Hi, It is nice to see how dynamically can be jira if our committers take care of the issues. Kudos to all of you making this happening! :-) Did you consider to do a 2.1 and 2.2 release after the GT? Best Regards, Antonio Gallardo.
Blueprint references
Hi there, for those interested, you can checkout current Blueprint code from the SourceSense SVN repository here : https://forge.pronetics.it/svn/scratchpad/blueprint/ We're arranging to put on line also a premade self installing jar file. Simone
[jira] Commented: (COCOON-1655) JavaFlow/CForm/select-list crash
[
http://issues.apache.org/jira/browse/COCOON-1655?page=comments#action_12439543
]
Simone Gianni commented on COCOON-1655:
---
I have it tested for javaflow 2.1, don't even know if 2.2 is affected by the
same problem and if this is a good solution for it as well. Should ask Torsten.
Anyway I'll commit the 2.1 fix ASAP.
JavaFlow/CForm/select-list crash
Key: COCOON-1655
URL: http://issues.apache.org/jira/browse/COCOON-1655
Project: Cocoon
Issue Type: Bug
Components: Blocks: Java Flow
Affects Versions: 2.1.7
Environment: Operating System: other
Platform: Other
Reporter: Benoit Deshaies
Assigned To: Cocoon Developers Team
Attachments: javaflow-continuationstack.diff
I get an error whenever I include an fd:selection-list src=cocoon:/XYZ
where
both the form and the XYZ pipeline use JavaFlow. The error is:
No continuation is running
cause: java.lang.IllegalStateException: No continuation is running
java.lang.IllegalStateException: No continuation is running
at
org.apache.cocoon.components.flow.java.Continuation.suspend(Continuation.java:79)
at
org.apache.cocoon.components.flow.java.AbstractContinuable.sendPageAndWait(AbstractContinuable.java:75)
at
org.apache.cocoon.forms.flow.java.FormInstance.show(FormInstance.java:181)
The reason is that when cocoon:/XYZ runs, a continuation is created for the
same
thread as the form continuation. The continuationsmap in Continuation class
gets
overwritten. When cocoon:/XYZ returns, the map is cleared for the thread,
leaving no continuation for the form.
Here's a bit of code from the app to help explain.
The form contains a selection list defined as:
fd:field id=user
fd:datatype base=string/
fd:selection-list src=cocoon:/UserSelectList dynamic=true/
/fd:field
The sitemap contains:
map:match pattern=UserSelectList
map:call function=generateUserList/
/map:match
Then I have the following JavaFlow
public void doGenerateUserList() throws Exception {
Collection userList = databaseManager.getUserList();
sendPage(user_list, new VarMap().add(list, userList) );
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Lars Trieloff as a new Cocoon committer
2006/10/3, Jean-Baptiste Quenot [EMAIL PROTECTED]: Dear Community, I think time has come for Lars Trieloff to become a Cocoon committer, so he'll be able to commit his numerous patches himself, including the last hair-pulling cocoon-core tests fixes today ;-) I know Lars since nearly 5 years as we were both contributing to the Docbook stuff. He is very professionnal and works in IT since the age of 20. He also wrote the online Docbook tool which allows to post a Docbook document and get the PDF in return, and he is the author of a Docbook book in German! And his current involvement into Cocoon 2.2 shows that he is already kind of committed to Cocoon, and since a few months he submitted very valuable patches. So please cast your votes! +1 -- Andreas
Re: [jira] Closed: (COCOON-1774) Fine Tuning Ajax Handling in CForms
Jean-Baptiste Quenot (JIRA) escribió: [ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) WDYT? Best Regards, Antonio Gallardo. Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Ajax Affects Versions: 2.1.8 Reporter: Eric Meyer Assigned To: Antonio Gallardo Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with fi:styling ajax='false' /, and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called.
Re: [jira] Closed: (COCOON-1774) Fine Tuning Ajax Handling in CForms
I just forgot to said, the below comment does not address concretely COCOON-1774. I think closing COCOON-1774 was a right decision. It is more about the process and not due this bug. I saw first: COCOON-1714, and I think it should not be closed until fixed. Best Regards, Antonio Gallardo. Antonio Gallardo escribió: Jean-Baptiste Quenot (JIRA) escribió: [ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) WDYT? Best Regards, Antonio Gallardo. Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Ajax Affects Versions: 2.1.8 Reporter: Eric Meyer Assigned To: Antonio Gallardo Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with fi:styling ajax='false' /, and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called.
can build cocoon after rev 452361
I get the following errors:
cocoon-block-forms-compile:
Compiling 379 source files to /home/ren/cocoon-2.1.10-dev/blocks/forms/dest
/home/ren/cocoon_2_1_x/src/blocks/forms/java/org/apache/cocoon/forms/util/JavaScriptHelper.java:213:
cannot find symbol
symbol : method unwrap(java.lang.Object)
location: class org.apache.cocoon.components.flow.util.PipelineUtil
return PipelineUtil.unwrap(result);
^
/home/ren/cocoon_2_1_x/src/blocks/forms/java/org/apache/cocoon/forms/util/JavaScriptHelper.java:243:
cannot find symbol
symbol : method unwrap(java.lang.Object)
location: class org.apache.cocoon.components.flow.util.PipelineUtil
return PipelineUtil.unwrap(result);
^
can anyone reproduce?
thanks,
Renaud
---
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/util/JavaScriptHelper.java
2006/09/23
03:58:05449149
+++
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/util/JavaScriptHelper.java
2006/10/03
09:19:08452361
@@ -24,6 +24,7 @@
import org.apache.avalon.framework.CascadingRuntimeException;
import org.apache.cocoon.components.flow.FlowHelper;
import
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptFlowHelper;
+import org.apache.cocoon.components.flow.util.PipelineUtil;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.Function;
import org.mozilla.javascript.JavaScriptException;
@@ -209,7 +210,7 @@
}
Object result = script.exec(ctx, scope);
-return FlowHelper.unwrap(result);
+return PipelineUtil.unwrap(result);
} finally {
Context.exit();
}
@@ -239,7 +240,7 @@
}
func.setParentScope(scope);
Object result = func.call(ctx, scope, thisObject == null?
null: Context.toObject(thisObject, scope), arguments);
-return FlowHelper.unwrap(result);
+return PipelineUtil.unwrap(result);
} finally {
Context.exit();
}
--
Renaud Richardet
COO America
Wyona- Open Source Content Management - Apache Lenya
office +1 857 776-3195 mobile +1 617 230 9112
renaud.richardet at wyona.com http://www.wyona.com
Re: [jira] Closed: (COCOON-1774) Fine Tuning Ajax Handling in CForms
Antonio Gallardo wrote: I just forgot to said, the below comment does not address concretely COCOON-1774. I think closing COCOON-1774 was a right decision. It is more about the process and not due this bug. I saw first: COCOON-1714, and I think it should not be closed until fixed. JFYI, there were no jira policy or process discussed at GT2006. Vadim Best Regards, Antonio Gallardo. Antonio Gallardo escribió: Jean-Baptiste Quenot (JIRA) escribió: [ http://issues.apache.org/jira/browse/COCOON-1774?page=all ] Jean-Baptiste Quenot closed COCOON-1774. Resolution: Won't Fix Please reopen the issue if the problem persists with the new Dojo stuff. Thanks! I don't think it is the best way to close bugs. IMHO, the first part of a problem resolution is the problem identification and an open issue without a patch provides this first part. I would left open this bug (and onther of the current closed) until somebody comes with a solution. I don't know if you talked about this in GT2006, but if jira now becomes only a patch repository, I will like to know. At least we should vote for this policy change. Please don't take it personally. ;-) WDYT? Best Regards, Antonio Gallardo. Fine Tuning Ajax Handling in CForms --- Key: COCOON-1774 URL: http://issues.apache.org/jira/browse/COCOON-1774 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms, Blocks: Ajax Affects Versions: 2.1.8 Reporter: Eric Meyer Assigned To: Antonio Gallardo Attachments: fi-styling-ajax-false.patch.txt Currently, it's all or nothing when it comes to using AJAX on a form. With this enhancement, form widgets can be marked with fi:styling ajax='false' /, and they will trigger a non-ajax form submission. This was particularly useful on the main submit buttons on a form inconjunction with the fi:validation-messages element (see http://issues.apache.org/jira/browse/COCOON-1570 for why fi:validation-messages doesn't work with AJAX). Regardless, I believe it is useful to give the developer control over which widgets use AJAX and which do not. Note that the patch files also include a fix to a separate AJAX issue. forms_onsubmitHandlers = null Causes problems when in AJAX mode - submit handlers are only called the first time an ajax submit is called. Thereafter, the array of handlers is null, and none are called.
Re: [VOTE] Lars Trieloff as a new Cocoon committer
+1 -David
Re: [VOTE] Lars Trieloff as a new Cocoon committer
+1 Best Regards, Antonio Gallardo.
Re: can build cocoon after rev 452361
Renaud Richardet escribió: I get the following errors: cocoon-block-forms-compile: Compiling 379 source files to /home/ren/cocoon-2.1.10-dev/blocks/forms/dest /home/ren/cocoon_2_1_x/src/blocks/forms/java/org/apache/cocoon/forms/util/JavaScriptHelper.java:213: cannot find symbol symbol : method unwrap(java.lang.Object) location: class org.apache.cocoon.components.flow.util.PipelineUtil return PipelineUtil.unwrap(result); ^ /home/ren/cocoon_2_1_x/src/blocks/forms/java/org/apache/cocoon/forms/util/JavaScriptHelper.java:243: cannot find symbol symbol : method unwrap(java.lang.Object) location: class org.apache.cocoon.components.flow.util.PipelineUtil return PipelineUtil.unwrap(result); ^ can anyone reproduce? I can reproduce it. Best Regards, Antonio Gallardo.
