[jira] Closed: (COCOON-2043) Thien Luh's new design of the Cocoon website
[ https://issues.apache.org/jira/browse/COCOON-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden closed COCOON-2043. Resolution: Fixed Thanks for reminding me. Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assignee: Helma van der Linden Attachments: Cocoon Site - Elements.zip, Home V2 - Final.psd, icons.rar, warning.gif Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2043) Thien Luh's new design of the Cocoon website
[ https://issues.apache.org/jira/browse/COCOON-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591062#action_12591062 ] Helma van der Linden commented on COCOON-2043: -- Decided to close the issue myself. Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assignee: Helma van der Linden Attachments: Cocoon Site - Elements.zip, Home V2 - Final.psd, icons.rar, warning.gif Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1680) New design/ layout proposal for Cocoon documentation
[ https://issues.apache.org/jira/browse/COCOON-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden closed COCOON-1680. Resolution: Won't Fix There is another redesign (COCOON-2043) implemented. New design/ layout proposal for Cocoon documentation Key: COCOON-1680 URL: https://issues.apache.org/jira/browse/COCOON-1680 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Milan Andrejevic Assignee: Cocoon Developers Team Priority: Minor Attachments: asf20051107.zip, asf20051108.zip, screenshot.gif, screenshot.gif I made new design/ layout proposal for Cocoon documentation. Just one html and screen css. I understand you need to modernize site (see Upayavira comment for COCOON-1679). This is my try, I hope you like it. There are two layouts user can choose. Layout info is stored in cookie _asfstyle for 30 days. Added access keys on top menu. Navigation on right contains only sub-section selected form top menu Minimal resolution set to 800px. Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you can find all picture slices. I have checked this design in: Windows: Firefox 1.0.7 Internet Explorer 6.0 Opera 8.5 Linux: Firefox 1.0.7 Konqueror 3.3.2 Mozilla 1.7.5 Netscape 7.2 Lynx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1686) [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace.
[
https://issues.apache.org/jira/browse/COCOON-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498239
]
Helma van der Linden commented on COCOON-1686:
--
The patch has the same effect as setting the parameter in cocoon.xconf:
xml-parser class=org.apache.excalibur.xml.impl.JaxpParser
logger=core.xml-parser pool-max=${xml-parser.pool-max}
parameter name=validate value=false/
parameter name=namespace-prefixes value=true/ !-- set to true to fix
namespacing problems --
parameter name=stop-on-warning value=true/
parameter name=stop-on-recoverable-error value=true/
parameter name=reuse-parsers value=false/
parameter name=drop-dtd-comments value=true/
/xml-parser
This is a more elegant solution.
[PATCH] COCOON-1671 Form not binding when prefix in binding definition is
unequal to that in the instance data for the same namespace.
--
Key: COCOON-1686
URL: https://issues.apache.org/jira/browse/COCOON-1686
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8
Reporter: Michael Schlotfeldt
Attachments: DomHelper.txt, JXPathBindingManager.txt
This is a patch to solve bug entry COCOON-1671.
The problem was the SAX parser used in createBinding(Source) of
JXPathBindingManager did not have the
http://xml.org/sax/features/namespace-prefixes; set to true. This ment the
namespaces could not be extracted from the DOM when calling
getInheritedNSDeclarations(Element). Therefore the JXPathContext was never
having namespaces registered.
Enabling the features solves these problems. The patch (which is against the
SVN as of today) that are being submit changes 2 files: (1) DomHelper.java
(2)JXPathBindingMangager
In DomHelper I added an additional parse method that takes a SAXParser in
place of the servicemanager. This way you can set features on the SAXParser
before the parsing to dom is done. The parse method that existed before still
does but i modified that as well so it uses the new method so we do not
duplicate code.
Three more things:
1. My experinece with Excalibur is not complete. I am unsure if i can lookup
the SAXParser and then parametize it. Or if it should be done another way.
The patch looks it up and then parametizes this. I believe this is the
correct way, but if it is not please let me know.
2. The SAXParser used by JXPathBindingMangager no turns on the feature we
want. But the JaxpParser class from Excalibur (which is what is returned) has
a system print out in it if you enable the feature we are now. So everytime
a binding occurs it says: NAMESPACE PREFIX!!. If
anybody has acces to the repository for that class PLEASE remove that line.
It shoudl not be there.
3. There is another bug report for the form samples (#6) that uses namespace
binding. I need somebody to confirm this but it appears that this patch also
fixes that bug report. The number for that report is: COCOON-1595
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2033) [PATCH] CForms pt_BR messages
[ https://issues.apache.org/jira/browse/COCOON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden reassigned COCOON-2033: Assignee: Helma van der Linden [PATCH] CForms pt_BR messages - Key: COCOON-2033 URL: https://issues.apache.org/jira/browse/COCOON-2033 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Assigned To: Helma van der Linden Attachments: cforms_pt_br.patch The patch contains brazilian portuguese translations for built-in CForms messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2033) [PATCH] CForms pt_BR messages
[ https://issues.apache.org/jira/browse/COCOON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491729 ] Helma van der Linden commented on COCOON-2033: -- Patch applied to trunk. I haven't been able to actually test the file in real-time, but I did verify the accented characters. [PATCH] CForms pt_BR messages - Key: COCOON-2033 URL: https://issues.apache.org/jira/browse/COCOON-2033 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Assigned To: Helma van der Linden Attachments: cforms_pt_br.patch The patch contains brazilian portuguese translations for built-in CForms messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2033) [PATCH] CForms pt_BR messages
[ https://issues.apache.org/jira/browse/COCOON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491744 ] Helma van der Linden commented on COCOON-2033: -- File copied to branch 2.1.X, no testing done. [PATCH] CForms pt_BR messages - Key: COCOON-2033 URL: https://issues.apache.org/jira/browse/COCOON-2033 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Assigned To: Helma van der Linden Attachments: cforms_pt_br.patch The patch contains brazilian portuguese translations for built-in CForms messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2033) [PATCH] CForms pt_BR messages
[ https://issues.apache.org/jira/browse/COCOON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden closed COCOON-2033. Resolution: Fixed Please reopen if something is wrong [PATCH] CForms pt_BR messages - Key: COCOON-2033 URL: https://issues.apache.org/jira/browse/COCOON-2033 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Gustavo N. Fernandes Assigned To: Helma van der Linden Attachments: cforms_pt_br.patch The patch contains brazilian portuguese translations for built-in CForms messages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2043) Thien Luh's new design of the Cocoon website
Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assigned To: Helma van der Linden Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2043) Thien Luh's new design of the Cocoon website
[ https://issues.apache.org/jira/browse/COCOON-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden updated COCOON-2043: - Attachment: Cocoon Site - Elements.zip CLA is recorded. Thien Luh's new design of the Cocoon website Key: COCOON-2043 URL: https://issues.apache.org/jira/browse/COCOON-2043 Project: Cocoon Issue Type: Improvement Components: - Documentation Reporter: Helma van der Linden Assigned To: Helma van der Linden Attachments: Cocoon Site - Elements.zip Thien Luh has provided a superb redesign of the website. Attached are the elements that make up the design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ https://issues.apache.org/jira/browse/COCOON-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487117 ] Helma van der Linden commented on COCOON-1622: -- I added the second patch, since it's the most complete version. I tested it in 2.1.9+, and works. To be on the safe side, someone should check it in the most recent version. [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: https://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Issue Type: Bug Components: Blocks: Mail Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assigned To: Jean-Baptiste Quenot Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ https://issues.apache.org/jira/browse/COCOON-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden reassigned COCOON-1622: Assignee: Helma van der Linden (was: Jean-Baptiste Quenot) [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: https://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Issue Type: Bug Components: Blocks: Mail Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assigned To: Helma van der Linden Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-1622) [PATCH] SendMailTransformer and HTML body
[ https://issues.apache.org/jira/browse/COCOON-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helma van der Linden closed COCOON-1622. Resolution: Fixed [PATCH] SendMailTransformer and HTML body - Key: COCOON-1622 URL: https://issues.apache.org/jira/browse/COCOON-1622 Project: Cocoon Issue Type: Bug Components: Blocks: Mail Affects Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Philippe Gassmann Assigned To: Helma van der Linden Attachments: 20051006-sendmailtr, 20051020-sendmailtr The SendMailTransformer is unable to handle XML tags directly in the SAX flow. ex : email:sendmail email:smtphostsmtp/email:smtphost email:from[EMAIL PROTECTED]/email:from email:to[EMAIL PROTECTED]/email:to email:subject Bogus sendmailtrasformer /email:subject email:body htmlbody pthis is a paragraph/p panother/p /body/html /email:body /email:sendmail It simply remove xml tags in the body ! It a a strange behaviour since DEFAULT_BODY_MIMETYPE = text/html ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-1896) Sendmail requires documentation on geronmio libraries
[ http://issues.apache.org/jira/browse/COCOON-1896?page=all ] Helma van der Linden reassigned COCOON-1896: Assignee: Helma van der Linden Sendmail requires documentation on geronmio libraries - Key: COCOON-1896 URL: http://issues.apache.org/jira/browse/COCOON-1896 Project: Cocoon Issue Type: Improvement Components: - Documentation Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: Kamal Bhatt Assigned To: Helma van der Linden Currently, if you want to use the sendmail action (http://cocoon.apache.org/2.1/userdocs/optional/sendmail-action.html), you must ensure that the geronimo-spec-javamail-*.jar and geronimo-spec-activation-*.jar are not bundled with your webapp. This is mentioned in wiki, but should be on the main website as it leads to strange behaviour (the email says it is sent successfully, but it is not sent at all). The same probably applies to the sendmail logicsheet (http://cocoon.apache.org/2.1/userdocs/logicsheets/sendmail.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1896) Sendmail requires documentation on geronmio libraries
[ http://issues.apache.org/jira/browse/COCOON-1896?page=all ] Helma van der Linden closed COCOON-1896. Resolution: Fixed This is already done for the sendmail-action, the sendmailTransformer and now the Sendmail Logicsheet. In the next update of the documentation on cocoon.apache.org the info should be available. Please note that there are some problems with updating the documentation site, so please be patient. If you find that after a few days the info is still not there, feel free to open this issue again. Sendmail requires documentation on geronmio libraries - Key: COCOON-1896 URL: http://issues.apache.org/jira/browse/COCOON-1896 Project: Cocoon Issue Type: Improvement Components: - Documentation Affects Versions: 2.1.8, 2.1.9, 2.1.10-dev (current SVN) Reporter: Kamal Bhatt Assigned To: Helma van der Linden Currently, if you want to use the sendmail action (http://cocoon.apache.org/2.1/userdocs/optional/sendmail-action.html), you must ensure that the geronimo-spec-javamail-*.jar and geronimo-spec-activation-*.jar are not bundled with your webapp. This is mentioned in wiki, but should be on the main website as it leads to strange behaviour (the email says it is sent successfully, but it is not sent at all). The same probably applies to the sendmail logicsheet (http://cocoon.apache.org/2.1/userdocs/logicsheets/sendmail.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1713) [LINK] www.mw-import.de
[ http://issues.apache.org/jira/browse/COCOON-1713?page=comments#action_12418400 ] Helma van der Linden commented on COCOON-1713: -- The url times out with a proxy error. I'll check later. If it stays unavailable, I'll close this issue. The author can reopen it, if necessary. [LINK] www.mw-import.de --- Key: COCOON-1713 URL: http://issues.apache.org/jira/browse/COCOON-1713 Project: Cocoon Type: Task Components: - Documentation Reporter: Jianyu Wang Priority: Trivial -URL of the website: http://www.mw-import.de -Title of the website: MW-Import Werkzeuge. -Cocoon version used: 2.1.7 - Short summary of your site: A German Web shop selling measurement tools imported from Asia. - How can we verify this site is actually built with Cocoon?: view response header. How much time did it take to build the site from design to publication? 6 month - How many people were involved in the project? one Java Developer and one Designer -How much traffic does the site handle? 100 User a day / 1500 Pages -What made you choose Cocoon to build the site? The main reason to that cocoon let us follow the MVC pattern and separate concerns. The Web designer was able to develop the style sheet totally independent of the application logic. All business logic could be encapsulated in services and tested with Junit outside the web container. At least the flow provide as facility to bind the web application together. As a bonus we easily can create Order documents in pdf. Beside the fact that cocoon is cool framework one of our partners used cocoon in former project. -What other information do you want to disclose- Main Parts used: Cocoon Form, Flow with Continuation, and FOP - Can you provide a contact email address if people want further information? I'm happy to share cocoon experience: [EMAIL PROTECTED] I hope i commited this task correctly bcause is the first time i use jira. Jianyu -- 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-1713) [LINK] www.mw-import.de
[ http://issues.apache.org/jira/browse/COCOON-1713?page=comments#action_12418429 ] Helma van der Linden commented on COCOON-1713: -- The information is added to the Live Sites and will be displayed on the main documentation site after the next doc updates. [LINK] www.mw-import.de --- Key: COCOON-1713 URL: http://issues.apache.org/jira/browse/COCOON-1713 Project: Cocoon Type: Task Components: - Documentation Reporter: Jianyu Wang Priority: Trivial -URL of the website: http://www.mw-import.de -Title of the website: MW-Import Werkzeuge. -Cocoon version used: 2.1.7 - Short summary of your site: A German Web shop selling measurement tools imported from Asia. - How can we verify this site is actually built with Cocoon?: view response header. How much time did it take to build the site from design to publication? 6 month - How many people were involved in the project? one Java Developer and one Designer -How much traffic does the site handle? 100 User a day / 1500 Pages -What made you choose Cocoon to build the site? The main reason to that cocoon let us follow the MVC pattern and separate concerns. The Web designer was able to develop the style sheet totally independent of the application logic. All business logic could be encapsulated in services and tested with Junit outside the web container. At least the flow provide as facility to bind the web application together. As a bonus we easily can create Order documents in pdf. Beside the fact that cocoon is cool framework one of our partners used cocoon in former project. -What other information do you want to disclose- Main Parts used: Cocoon Form, Flow with Continuation, and FOP - Can you provide a contact email address if people want further information? I'm happy to share cocoon experience: [EMAIL PROTECTED] I hope i commited this task correctly bcause is the first time i use jira. Jianyu -- 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-1713) [LINK] www.mw-import.de
[ http://issues.apache.org/jira/browse/COCOON-1713?page=all ] Helma van der Linden closed COCOON-1713: Resolution: Fixed [LINK] www.mw-import.de --- Key: COCOON-1713 URL: http://issues.apache.org/jira/browse/COCOON-1713 Project: Cocoon Type: Task Components: - Documentation Reporter: Jianyu Wang Priority: Trivial -URL of the website: http://www.mw-import.de -Title of the website: MW-Import Werkzeuge. -Cocoon version used: 2.1.7 - Short summary of your site: A German Web shop selling measurement tools imported from Asia. - How can we verify this site is actually built with Cocoon?: view response header. How much time did it take to build the site from design to publication? 6 month - How many people were involved in the project? one Java Developer and one Designer -How much traffic does the site handle? 100 User a day / 1500 Pages -What made you choose Cocoon to build the site? The main reason to that cocoon let us follow the MVC pattern and separate concerns. The Web designer was able to develop the style sheet totally independent of the application logic. All business logic could be encapsulated in services and tested with Junit outside the web container. At least the flow provide as facility to bind the web application together. As a bonus we easily can create Order documents in pdf. Beside the fact that cocoon is cool framework one of our partners used cocoon in former project. -What other information do you want to disclose- Main Parts used: Cocoon Form, Flow with Continuation, and FOP - Can you provide a contact email address if people want further information? I'm happy to share cocoon experience: [EMAIL PROTECTED] I hope i commited this task correctly bcause is the first time i use jira. Jianyu -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1713) [LINK] www.mw-import.de
[ http://issues.apache.org/jira/browse/COCOON-1713?page=all ] Helma van der Linden reassigned COCOON-1713: Assign To: Helma van der Linden [LINK] www.mw-import.de --- Key: COCOON-1713 URL: http://issues.apache.org/jira/browse/COCOON-1713 Project: Cocoon Type: Task Components: - Documentation Reporter: Jianyu Wang Assignee: Helma van der Linden Priority: Trivial -URL of the website: http://www.mw-import.de -Title of the website: MW-Import Werkzeuge. -Cocoon version used: 2.1.7 - Short summary of your site: A German Web shop selling measurement tools imported from Asia. - How can we verify this site is actually built with Cocoon?: view response header. How much time did it take to build the site from design to publication? 6 month - How many people were involved in the project? one Java Developer and one Designer -How much traffic does the site handle? 100 User a day / 1500 Pages -What made you choose Cocoon to build the site? The main reason to that cocoon let us follow the MVC pattern and separate concerns. The Web designer was able to develop the style sheet totally independent of the application logic. All business logic could be encapsulated in services and tested with Junit outside the web container. At least the flow provide as facility to bind the web application together. As a bonus we easily can create Order documents in pdf. Beside the fact that cocoon is cool framework one of our partners used cocoon in former project. -What other information do you want to disclose- Main Parts used: Cocoon Form, Flow with Continuation, and FOP - Can you provide a contact email address if people want further information? I'm happy to share cocoon experience: [EMAIL PROTECTED] I hope i commited this task correctly bcause is the first time i use jira. Jianyu -- 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-1850) [Link] Dutch Ministry of Finance - www.minfin.nl
[ http://issues.apache.org/jira/browse/COCOON-1850?page=all ] Helma van der Linden closed COCOON-1850: Resolution: Fixed I am closing this issue. If Arje would like to add additional information to the Daisy entry, he can do so on his own. [Link] Dutch Ministry of Finance - www.minfin.nl Key: COCOON-1850 URL: http://issues.apache.org/jira/browse/COCOON-1850 Project: Cocoon Type: Task Components: - Documentation Versions: 2.1.8 Reporter: Arjé Cahn Assignee: Helma van der Linden Priority: Trivial URL of the website: www.minfin.nl Title of the website: Dutch Ministry of Finance Cocoon version used: 2.1.8 Short summary: The main website of the Dutch Ministry of Finance (www.minfin.nl). Built entirely in Cocoon 2.1.8 and launched in April, 2006. Total development time took around 4 months. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1660) [Link] Warsztat
[ http://issues.apache.org/jira/browse/COCOON-1660?page=all ] Helma van der Linden reassigned COCOON-1660: Assign To: Helma van der Linden (was: Cocoon Developers Team) [Link] Warsztat --- Key: COCOON-1660 URL: http://issues.apache.org/jira/browse/COCOON-1660 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Reporter: Grzegorz Kossakowski (aka g[R]eK) Assignee: Helma van der Linden Priority: Minor URL of the website: http://www.gamedev.pl Title of the website: Warsztat Cocoon version used: 2.1.7 Short summary: Polish site in early stage of development that aims at keeping polish game programming community together and provide some useful resources. How can we verify this site is actually built with Cocoon? Check HTTP headers. -- 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-1660) [Link] Warsztat
[ http://issues.apache.org/jira/browse/COCOON-1660?page=all ] Helma van der Linden closed COCOON-1660: Resolution: Fixed Added to the list of Live Sites built with Cocoon 2.1.7 [Link] Warsztat --- Key: COCOON-1660 URL: http://issues.apache.org/jira/browse/COCOON-1660 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Reporter: Grzegorz Kossakowski (aka g[R]eK) Assignee: Helma van der Linden Priority: Minor URL of the website: http://www.gamedev.pl Title of the website: Warsztat Cocoon version used: 2.1.7 Short summary: Polish site in early stage of development that aims at keeping polish game programming community together and provide some useful resources. How can we verify this site is actually built with Cocoon? Check HTTP headers. -- 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-1659) Finish the sitemap internals document in Daisy
[ http://issues.apache.org/jira/browse/COCOON-1659?page=all ] Helma van der Linden closed COCOON-1659: Resolution: Fixed No feedback in 4 months so I assume that the text is ok. Finish the sitemap internals document in Daisy -- Key: COCOON-1659 URL: http://issues.apache.org/jira/browse/COCOON-1659 Project: Cocoon Type: Task Components: - Documentation Versions: 2.2-dev (Current SVN) Reporter: Helma van der Linden Assignee: Helma van der Linden Priority: Minor Attachments: svgs-of-article.zip Text and images of the description of the sitemap processing should be enhanced and reviewed. http://cocoon.zones.apache.org/daisy/documentation/732.html - integrate related wiki pages: http://wiki.apache.org/cocoon/InterpretedSitemapInternals http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes - Review of the content by sitemap experts (Sylvain?) - Create better images (see also pages on wiki page) - add links to appropriate classes into apidocs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1856) [Link] www.pyxx.org
[ http://issues.apache.org/jira/browse/COCOON-1856?page=all ] Helma van der Linden reassigned COCOON-1856: Assign To: Helma van der Linden [Link] www.pyxx.org --- Key: COCOON-1856 URL: http://issues.apache.org/jira/browse/COCOON-1856 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8 Reporter: Sasha Philippov Assignee: Helma van der Linden Priority: Minor Pyxx.org - live site on XML-related authoring and publishing for web and on-line learning. URL: http://www.pyxx.org Cocoon version used: 2.1.8 It took five days for one programmer to develop and set up the site. You can see the description of the hosting solution (Apache, Tomcat, Cocoon) here: http://www.pyxx.org/cocoon/vhosting/howto.html The site full sources are available for download here: http://www.pyxx.org/cocoon/thesite/sitemap.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1856) [Link] www.pyxx.org
[ http://issues.apache.org/jira/browse/COCOON-1856?page=all ] Helma van der Linden closed COCOON-1856: Resolution: Fixed The information is added to Live Sites. [Link] www.pyxx.org --- Key: COCOON-1856 URL: http://issues.apache.org/jira/browse/COCOON-1856 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8 Reporter: Sasha Philippov Assignee: Helma van der Linden Priority: Minor Pyxx.org - live site on XML-related authoring and publishing for web and on-line learning. URL: http://www.pyxx.org Cocoon version used: 2.1.8 It took five days for one programmer to develop and set up the site. You can see the description of the hosting solution (Apache, Tomcat, Cocoon) here: http://www.pyxx.org/cocoon/vhosting/howto.html The site full sources are available for download here: http://www.pyxx.org/cocoon/thesite/sitemap.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1730) [Link] Computer Science Department 2 - University of Erlangen-Nuremberg
[ http://issues.apache.org/jira/browse/COCOON-1730?page=all ] Helma van der Linden reassigned COCOON-1730: Assign To: Helma van der Linden [Link] Computer Science Department 2 - University of Erlangen-Nuremberg --- Key: COCOON-1730 URL: http://issues.apache.org/jira/browse/COCOON-1730 Project: Cocoon Type: Wish Components: - Documentation Versions: 2.1.8 Reporter: Thorsten Meinl Assignee: Helma van der Linden URL of the website: http://www2.informatik.uni-erlangen.de/ Title of the website: Computer Science Department 2 Cocoon version used: 2.1.8 Short summary: Webpages of the programming systems group at the Friedrich-Alexander University Erlangen-Nuremberg How can we verify this site is actually built with Cocoon? http://www2.informatik.uni-erlangen.de/cocoon-status.xml - How much time did it take to build the site from design to publication? 2 months - How much traffic does the site handle? ~300MB/day, ~15,000 hits/day - What made you choose Cocoon to build the site? Our university-wide information system (UnivIS, http://univis.uni-erlangen.de/) offers an XML export of all data (lecture, publications, person, projects, ...) To avoid maintaining the data at multiple places we import these data and use Cocoon to produce our webpages more or less automatically - What other information do you want to disclose (e.g. how does it work, how didyou build it, what parts of Cocoon did you use)? Most importantly, we use eXist as XML database to store the imported data and use the XMLDBTransformer to include it into the pipeline. - Can you provide a contact email address if people want further information? [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1730) [Link] Computer Science Department 2 - University of Erlangen-Nuremberg
[ http://issues.apache.org/jira/browse/COCOON-1730?page=all ] Helma van der Linden closed COCOON-1730: Resolution: Fixed Information is added to the Live Sites pages. [Link] Computer Science Department 2 - University of Erlangen-Nuremberg --- Key: COCOON-1730 URL: http://issues.apache.org/jira/browse/COCOON-1730 Project: Cocoon Type: Wish Components: - Documentation Versions: 2.1.8 Reporter: Thorsten Meinl Assignee: Helma van der Linden URL of the website: http://www2.informatik.uni-erlangen.de/ Title of the website: Computer Science Department 2 Cocoon version used: 2.1.8 Short summary: Webpages of the programming systems group at the Friedrich-Alexander University Erlangen-Nuremberg How can we verify this site is actually built with Cocoon? http://www2.informatik.uni-erlangen.de/cocoon-status.xml - How much time did it take to build the site from design to publication? 2 months - How much traffic does the site handle? ~300MB/day, ~15,000 hits/day - What made you choose Cocoon to build the site? Our university-wide information system (UnivIS, http://univis.uni-erlangen.de/) offers an XML export of all data (lecture, publications, person, projects, ...) To avoid maintaining the data at multiple places we import these data and use Cocoon to produce our webpages more or less automatically - What other information do you want to disclose (e.g. how does it work, how didyou build it, what parts of Cocoon did you use)? Most importantly, we use eXist as XML database to store the imported data and use the XMLDBTransformer to include it into the pipeline. - Can you provide a contact email address if people want further information? [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1850) [Link] Dutch Ministry of Finance - www.minfin.nl
[ http://issues.apache.org/jira/browse/COCOON-1850?page=all ] Helma van der Linden reassigned COCOON-1850: Assign To: Helma van der Linden [Link] Dutch Ministry of Finance - www.minfin.nl Key: COCOON-1850 URL: http://issues.apache.org/jira/browse/COCOON-1850 Project: Cocoon Type: Task Components: - Documentation Versions: 2.1.8 Reporter: Arjé Cahn Assignee: Helma van der Linden Priority: Trivial URL of the website: www.minfin.nl Title of the website: Dutch Ministry of Finance Cocoon version used: 2.1.8 Short summary: The main website of the Dutch Ministry of Finance (www.minfin.nl). Built entirely in Cocoon 2.1.8 and launched in April, 2006. Total development time took around 4 months. -- 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-1850) [Link] Dutch Ministry of Finance - www.minfin.nl
[ http://issues.apache.org/jira/browse/COCOON-1850?page=comments#action_12412304 ] Helma van der Linden commented on COCOON-1850: -- Info added to Daisy: http://cocoon.zones.apache.org/daisy/documentation/695/705.html It would be nice if you could add the following info: - contact: (e.g. www.hippo.nl) - the number of people involved in making this happen in 4 months. - maybe some indication of the traffic? [Link] Dutch Ministry of Finance - www.minfin.nl Key: COCOON-1850 URL: http://issues.apache.org/jira/browse/COCOON-1850 Project: Cocoon Type: Task Components: - Documentation Versions: 2.1.8 Reporter: Arjé Cahn Assignee: Helma van der Linden Priority: Trivial URL of the website: www.minfin.nl Title of the website: Dutch Ministry of Finance Cocoon version used: 2.1.8 Short summary: The main website of the Dutch Ministry of Finance (www.minfin.nl). Built entirely in Cocoon 2.1.8 and launched in April, 2006. Total development time took around 4 months. -- 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-1818) SendMailTransformer misses closing tag when recipient address is malformed
[ http://issues.apache.org/jira/browse/COCOON-1818?page=comments#action_12372459 ] Helma van der Linden commented on COCOON-1818: -- Sorry to chip in so late, but when I was looking at this class I noticed a FIXME that states that it would be a good idea to use the same MailSender component that is used for the SendMailAction and SendMail XSP logicsheet. I've started working on this and it seemed rather straightforward, but unfortunately something crashed and I lost the modified code before I was able to properly finish and test it. So how about killing two birds with one stone and see if the class can be improved by using the MailSender component as well as fixing this bug? Maybe using the component already fixes this bug. At the very least, the behaviour will be consistent. SendMailTransformer misses closing tag when recipient address is malformed -- Key: COCOON-1818 URL: http://issues.apache.org/jira/browse/COCOON-1818 Project: Cocoon Type: Bug Components: Blocks: Mail Reporter: Jasha Joachimsthal Attachments: sendmail-exceptions.diff, sendmail-exceptions2.diff When a recipient address contains an illegal character (, ; space [EMAIL PROTECTED]@com etc), an exception is being thrown by method sendMail(List newAddresses, Transport trans). The execution of the try in method sendMail() is stopped which may have created a email:result tag. No /email:result end tag is created when this occurs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function
[ http://issues.apache.org/jira/browse/COCOON-1798?page=all ] Helma van der Linden reassigned COCOON-1798: Assign To: Helma van der Linden Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function --- Key: COCOON-1798 URL: http://issues.apache.org/jira/browse/COCOON-1798 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8 Reporter: Grzegorz Kossakowski (aka g[R]eK) Assignee: Helma van der Linden Nothing needed to add to the summury ;-) I think it should be fixed soon. -- 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-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function
[ http://issues.apache.org/jira/browse/COCOON-1798?page=all ] Helma van der Linden closed COCOON-1798: Resolution: Fixed Information is added to the Daisy documentation and will be reflected in the next documentation update. Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function --- Key: COCOON-1798 URL: http://issues.apache.org/jira/browse/COCOON-1798 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8 Reporter: Grzegorz Kossakowski (aka g[R]eK) Assignee: Helma van der Linden Nothing needed to add to the summury ;-) I think it should be fixed soon. -- 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-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function
[ http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369743 ] Helma van der Linden commented on COCOON-1798: -- I'm not sure what you want to happen. If it's merely an extension to the documentation I'd be happy to add it if you can provide a sensible description of the isGlobal parameter (i.e. something more sensible than global redirect). Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function --- Key: COCOON-1798 URL: http://issues.apache.org/jira/browse/COCOON-1798 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8 Reporter: Grzegorz Kossakowski (aka g[R]eK) Nothing needed to add to the summury ;-) I think it should be fixed soon. -- 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-1659) Finish the sitemap internals document in Daisy
[ http://issues.apache.org/jira/browse/COCOON-1659?page=all ] Helma van der Linden updated COCOON-1659: - Attachment: svgs-of-article.zip The zip includes the original SVG files that are used to generate the pictures used in the document. Finish the sitemap internals document in Daisy -- Key: COCOON-1659 URL: http://issues.apache.org/jira/browse/COCOON-1659 Project: Cocoon Type: Task Components: - Documentation Versions: 2.2-dev (Current SVN) Reporter: Helma van der Linden Assignee: Helma van der Linden Priority: Minor Attachments: svgs-of-article.zip Text and images of the description of the sitemap processing should be enhanced and reviewed. http://cocoon.zones.apache.org/daisy/documentation/732.html - integrate related wiki pages: http://wiki.apache.org/cocoon/InterpretedSitemapInternals http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes - Review of the content by sitemap experts (Sylvain?) - Create better images (see also pages on wiki page) - add links to appropriate classes into apidocs -- 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-1659) Finish the sitemap internals document in Daisy
[ http://issues.apache.org/jira/browse/COCOON-1659?page=comments#action_12367215 ] Helma van der Linden commented on COCOON-1659: -- Text is adjusted and images are redrawn. Feedback of the experts is wanted! Finish the sitemap internals document in Daisy -- Key: COCOON-1659 URL: http://issues.apache.org/jira/browse/COCOON-1659 Project: Cocoon Type: Task Components: - Documentation Versions: 2.2-dev (Current SVN) Reporter: Helma van der Linden Assignee: Helma van der Linden Priority: Minor Text and images of the description of the sitemap processing should be enhanced and reviewed. http://cocoon.zones.apache.org/daisy/documentation/732.html - integrate related wiki pages: http://wiki.apache.org/cocoon/InterpretedSitemapInternals http://wiki.apache.org/cocoon/GT2005HackatonDay1Notes - Review of the content by sitemap experts (Sylvain?) - Create better images (see also pages on wiki page) - add links to appropriate classes into apidocs -- 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-1688) Error in the CForms Library samples
Error in the CForms Library samples --- Key: COCOON-1688 URL: http://issues.apache.org/jira/browse/COCOON-1688 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Helma van der Linden http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow shows: java.lang.Exception: A widget name cannot contain ':' as this conflicts with library prefixes, at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/library/forms/form1_model.xml:24:30 context://samples/blocks/forms/library/forms/form1_model.xml - 24:30 -- 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-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12357148 ] Helma van der Linden commented on COCOON-1680: -- Right, I like the second version better, because it's less cluttered, but Upayavira is right: it still has strong resemblance to the old site. Do get wild and surprise us. I'd suggest to stick with blue (in whatever shade) to link back to old site. Also, keep the Cocoon logo (the white letters with the dots). I'm not sure if you can remove the apache logo with the feather (and just keep the feather), i.e. if there are rules on that. It would surely free up space. Keep up the good work. New design/ layout proposal for Cocoon documentation Key: COCOON-1680 URL: http://issues.apache.org/jira/browse/COCOON-1680 Project: Cocoon Type: Improvement Components: - Documentation Reporter: Milan Andrejevic Priority: Minor Attachments: asf20051107.zip, asf20051108.zip, screenshot.gif, screenshot.gif I made new design/ layout proposal for Cocoon documentation. Just one html and screen css. I understand you need to modernize site (see Upayavira comment for COCOON-1679). This is my try, I hope you like it. There are two layouts user can choose. Layout info is stored in cookie _asfstyle for 30 days. Added access keys on top menu. Navigation on right contains only sub-section selected form top menu Minimal resolution set to 800px. Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you can find all picture slices. I have checked this design in: Windows: Firefox 1.0.7 Internet Explorer 6.0 Opera 8.5 Linux: Firefox 1.0.7 Konqueror 3.3.2 Mozilla 1.7.5 Netscape 7.2 Lynx -- 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-1680) New design/ layout proposal for Cocoon documentation
[ http://issues.apache.org/jira/browse/COCOON-1680?page=comments#action_12356951 ] Helma van der Linden commented on COCOON-1680: -- Thanks for the work done, it really looks much more modern. I like the general layout and the simplicity of the menu and main content window. I noticed a kind of top level menu in the bar at the top. I find this very cluttered, i.e. too many entries. Maybe you could go one level up for that or reduce it to: - about Cocoon (about us, status, and other info on downloads, svn access, mailing list, links etc) - user guide (narrative info about Cocoon, i.e. explanations of concepts, beginners' info etc) - reference guide (more in-depth info about various aspects of Cocoon) - apidocs and the two Cocoon/ASF links at the right. I do like this: simple and clear. Although you might change ASF to Apache since not every one is familiar with the meaning of ASF. I noticed lines above certain letters of the links. I assume they are used for keyboard shortcuts? If so, the idea is fabulous, but I would suggest to move the line below the letter or change the color of the letter. Both are more compatible with user expectations. I like it that the search bar is less prominent but as a whole I find the top block very cluttered. Is it possible to reduce the left image with the feather? New design/ layout proposal for Cocoon documentation Key: COCOON-1680 URL: http://issues.apache.org/jira/browse/COCOON-1680 Project: Cocoon Type: Improvement Components: - Documentation Reporter: Milan Andrejevic Priority: Minor Attachments: asf20051107.zip, screenshot.gif I made new design/ layout proposal for Cocoon documentation. Just one html and screen css. I understand you need to modernize site (see Upayavira comment for COCOON-1679). This is my try, I hope you like it. There are two layouts user can choose. Layout info is stored in cookie _asfstyle for 30 days. Added access keys on top menu. Navigation on right contains only sub-section selected form top menu Minimal resolution set to 800px. Starting design is done in Macromedia Fireworks (_src/cocoon.png) were you can find all picture slices. I have checked this design in: Windows: Firefox 1.0.7 Internet Explorer 6.0 Opera 8.5 Linux: Firefox 1.0.7 Konqueror 3.3.2 Mozilla 1.7.5 Netscape 7.2 Lynx -- 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-1626) [Link] Polska Strefa
[ http://issues.apache.org/jira/browse/COCOON-1626?page=all ] Helma van der Linden closed COCOON-1626: Resolution: Fixed Probably a misunderstanding in the description: the information is added to the Cocoon Live Site page for Cocoon 2.1.6 in the Daisy documentation repository, which will be exported to the official Cocoon documentation site when the next version of Cocoon is released. [Link] Polska Strefa Key: COCOON-1626 URL: http://issues.apache.org/jira/browse/COCOON-1626 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: All Reporter: Grzegorz TaÅczyk Assignee: Cocoon Developers Team Priority: Minor URL of the website: http://www.classifieds.pl Title of the website: Polska Strefa Cocoon version used: 2.1.6 Short summary: Polish website with classified ads How can we verify this site is actually built with Cocoon? Beacause I posted few times since last year on users@cocoon.apache.org ? - How much time did it take to build the site from design to publication? 2 months, but it is still under developement. New important improvements are still pedning. - How much traffic does the site handle? About 40.000 sessions each day - What made you choose Cocoon to build the site? 1. Java 2. XML - What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? I didn't use Flow, CForms, Portal Framework, SQLTransformer or Database Actions etc. It is based on my own Actions, Generators, Readers. Cron Scheduler is an important part there. I decided to use PostgreSQL as database engine. - Can you provide a contact email address if people want further information? [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-1455) [Link] TanakhML Project
[ http://issues.apache.org/jira/browse/COCOON-1455?page=all ] Helma van der Linden reopened COCOON-1455: -- reopened just to set the resolution to fixed [Link] TanakhML Project --- Key: COCOON-1455 URL: http://issues.apache.org/jira/browse/COCOON-1455 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Alain Verboomen Assignee: Cocoon Developers Team Priority: Minor URL of the website: http://www.tanakhml.org Title of the website: TanakhML Project Cocoon version used: 2.1.5 Short summary: Hebrew text of the Bible and online related tools: Hebrew/English text browser, verse accentual structure analyser, form concordancer. How can we verify this site is actually built with Cocoon? Please, contact our webhosting company, StarLine ([EMAIL PROTECTED]), one of the Cocoon webhosting solutions you mention on your site - they know our site is actually built with Cocoon. The following questions are optional: - How much time did it take to build the site from design to publication? About 14 months (1 person). - How much traffic does the site handle? Currently, about 1GB/month, but this site is in production since a few months only, so we still don't actually know how much traffic it will handle in the future. - What made you choose Cocoon to build the site? 1° Separation of concerns 2° Ability to generate, from a single dynamically generated XML file, as many formats as needed (HTML, PDF, and so on). - What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? It actually works fine! - Can you provide a contact email address if people want further information? Yes, my pleasure: [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1455) [Link] TanakhML Project
[ http://issues.apache.org/jira/browse/COCOON-1455?page=all ] Helma van der Linden closed COCOON-1455: Resolution: Fixed closed with resolution = fixed [Link] TanakhML Project --- Key: COCOON-1455 URL: http://issues.apache.org/jira/browse/COCOON-1455 Project: Cocoon Type: Improvement Components: - Documentation Versions: 2.1.7 Environment: Operating System: All Platform: All Reporter: Alain Verboomen Assignee: Cocoon Developers Team Priority: Minor URL of the website: http://www.tanakhml.org Title of the website: TanakhML Project Cocoon version used: 2.1.5 Short summary: Hebrew text of the Bible and online related tools: Hebrew/English text browser, verse accentual structure analyser, form concordancer. How can we verify this site is actually built with Cocoon? Please, contact our webhosting company, StarLine ([EMAIL PROTECTED]), one of the Cocoon webhosting solutions you mention on your site - they know our site is actually built with Cocoon. The following questions are optional: - How much time did it take to build the site from design to publication? About 14 months (1 person). - How much traffic does the site handle? Currently, about 1GB/month, but this site is in production since a few months only, so we still don't actually know how much traffic it will handle in the future. - What made you choose Cocoon to build the site? 1° Separation of concerns 2° Ability to generate, from a single dynamically generated XML file, as many formats as needed (HTML, PDF, and so on). - What other information do you want to disclose (e.g. how does it work, how did you build it, what parts of Cocoon did you use)? It actually works fine! - Can you provide a contact email address if people want further information? Yes, my pleasure: [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-7) Oracle Support in build.xml
[ http://issues.apache.org/jira/browse/COCOON-7?page=all ] Helma van der Linden reopened COCOON-7: --- Assign To: (was: Giacomo Pati) reopened just to set the resolution to fixed Oracle Support in build.xml --- Key: COCOON-7 URL: http://issues.apache.org/jira/browse/COCOON-7 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Alpha Environment: Operating System: Linux Platform: PC Reporter: mkamp Priority: Minor After running ANT I get the below posted error message. Before that it is checked in the build.xml if a particular oracle class is present. This class seems to be present on my system. Nevertheless oracle.jdbc.OracleResultSet is not present on my system but referenced. I can work around with removing the test for oracle, so that everything is compiled without the oracle support. Mariano compile: [copy] Copying 1 file to /home/mkamp/xml-cocoon/build/cocoon/classes [javac] Compiling 3 source files to /home/mkamp/xml-cocoon/build/cocoon/classes [javac] /home/mkamp/xml-cocoon/build/cocoon/src/org/apache/cocoon/acting/OraAddAction.java:24: Class oracle.jdbc.OracleResultSet not found in import. [javac] import oracle.jdbc.OracleResultSet; [javac]^ [javac] 1 error BUILD FAILED /home/mkamp/xml-cocoon/build.xml:312: Compile failed, messages should have been provided. -- 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] Reopened: (COCOON-8) SVG broken - org.w3c.dom.css.CSSValue: method getCssValueType()S not found
[ http://issues.apache.org/jira/browse/COCOON-8?page=all ] Helma van der Linden reopened COCOON-8: --- Assign To: (was: Giacomo Pati) reopened just to set the resolution to fixed SVG broken - org.w3c.dom.css.CSSValue: method getCssValueType()S not found -- Key: COCOON-8 URL: http://issues.apache.org/jira/browse/COCOON-8 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Alpha Environment: Operating System: Linux Platform: PC Reporter: mkamp Priority: Blocker By running the am example, I get the below posted exception. I guess it is a problem with incompatibility of the libaries or possible the wrong order of the libraries. My classpath looks like this. /home/mkamp/lib/ant.jar:/home/mkamp/lib/batik-awt-util.jar:/home/mkamp/lib/batik-bridge.jar:/home/mkamp/lib/batik-css.jar:/home/mkamp/lib/batik-dom.jar:/home/mkamp/lib/batik-ext.jar:/home/mkamp/lib/batik-gui-util.jar:/home/mkamp/lib/batik-gvt.jar:/home/mkamp/lib/batik-parser.jar:/home/mkamp/lib/batik-script.jar:/home/mkamp/lib/batik-svg-dom.jar:/home/mkamp/lib/batik-svggen.jar:/home/mkamp/lib/batik-transcoder.jar:/home/mkamp/lib/batik-util.jar:/home/mkamp/lib/batik-xml.jar:/home/mkamp/lib/bsf.jar:/home/mkamp/lib/fop.jar:/home/mkamp/lib/jakarta-ant-1.3-optional.jar:/home/mkamp/lib/jakarta-regexp-1.3-dev.jar:/home/mkamp/lib/jcert.jar:/home/mkamp/lib/jmxgrinder.jar:/home/mkamp/lib/jmxri.jar:/home/mkamp/lib/jmxtools.jar:/home/mkamp/lib/jnet.jar:/home/mkamp/lib/jsse.jar:/home/mkamp/lib/junit.jar:/home/mkamp/lib/log4j-core.jar:/home/mkamp/lib/oracleClasses12.jar:/home/mkamp/lib/servlet.jar:/home/mkamp/lib/xalan122.jar:/home/mkamp/lib/xalan2.jar:/home/mkamp/lib/xerces.jar:/home/mkamp/lib/zservlet.jar:/home/mkamp/lib/zw3c.jar - Root Cause - java.lang.NoSuchMethodError: org.w3c.dom.css.CSSValue: method getCssValueType()S not found at org.apache.batik.bridge.CSSUtilities.convertVisibility(CSSUtilities.java:283) at org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(SVGSVGElementBridge.java:49) at org.apache.batik.bridge.ConcreteGVTBuilder.build(ConcreteGVTBuilder.java:78) at org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:190) at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:122) at org.apache.cocoon.serialization.SVGSerializer.notify(SVGSerializer.java:210) at org.apache.cocoon.xml.dom.SVGBuilder.endDocument(SVGBuilder.java:107) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:51) at org.apache.cocoon.xml.dom.DOMStreamer.setDocument(DOMStreamer.java:153) at org.apache.cocoon.xml.dom.DOMStreamer.processNode(DOMStreamer.java:98) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:84) at org.apache.cocoon.generation.FragmentExtractorGenerator.generate(FragmentExtractorGenerator.java:103) at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:221) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:345) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1790) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1392) at org.apache.cocoon.sitemap.Handler.process(Handler.java:159) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:97) at org.apache.cocoon.Cocoon.process(Cocoon.java:288) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:442) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:254) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at
[jira] Reopened: (COCOON-22) Additional newline after some tags like /table or /tr
[ http://issues.apache.org/jira/browse/COCOON-22?page=all ] Helma van der Linden reopened COCOON-22: reopened just to set the resolution to fixed Additional newline after some tags like /table or /tr - Key: COCOON-22 URL: http://issues.apache.org/jira/browse/COCOON-22 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Beta 1 Environment: Operating System: All Platform: All Reporter: Joern Heid Assignee: Cocoon Developers Team I want to remove newlines (or spaces) from my output. It seems the HTML serializer causes the problem (Xalan commandline, xml-serializer work correctly)... With this stylesheet /tableimg src=/images/empty.gif width=1 height=10 border=1/table... I get this with the xml serializer /tableimg border=1 height=10 width=1 src=/images/empty.gif/table... The same with Xalan (2.1) from the comandline /tableimg border=1 height=10 width=1 src=/images/empty.giftable... BUT I get this with the html serializer (see the newline) /table img border=1 height=10 width=1 src=/images/empty.giftable Is it a bug (Cocoon, SAX-Xalan)? Please help. In my stylesheet I do have xsl:output method=html indent=no/ xsl:strip-space elements=*/ JOERN_HEID -- 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-22) Additional newline after some tags like /table or /tr
[ http://issues.apache.org/jira/browse/COCOON-22?page=all ] Helma van der Linden closed COCOON-22: -- Resolution: Fixed closed with resolution = fixed Additional newline after some tags like /table or /tr - Key: COCOON-22 URL: http://issues.apache.org/jira/browse/COCOON-22 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Beta 1 Environment: Operating System: All Platform: All Reporter: Joern Heid Assignee: Cocoon Developers Team I want to remove newlines (or spaces) from my output. It seems the HTML serializer causes the problem (Xalan commandline, xml-serializer work correctly)... With this stylesheet /tableimg src=/images/empty.gif width=1 height=10 border=1/table... I get this with the xml serializer /tableimg border=1 height=10 width=1 src=/images/empty.gif/table... The same with Xalan (2.1) from the comandline /tableimg border=1 height=10 width=1 src=/images/empty.giftable... BUT I get this with the html serializer (see the newline) /table img border=1 height=10 width=1 src=/images/empty.giftable Is it a bug (Cocoon, SAX-Xalan)? Please help. In my stylesheet I do have xsl:output method=html indent=no/ xsl:strip-space elements=*/ JOERN_HEID -- 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-8) SVG broken - org.w3c.dom.css.CSSValue: method getCssValueType()S not found
[ http://issues.apache.org/jira/browse/COCOON-8?page=all ] Helma van der Linden closed COCOON-8: - Resolution: Fixed closed with resolution = fixed SVG broken - org.w3c.dom.css.CSSValue: method getCssValueType()S not found -- Key: COCOON-8 URL: http://issues.apache.org/jira/browse/COCOON-8 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Alpha Environment: Operating System: Linux Platform: PC Reporter: mkamp Priority: Blocker By running the am example, I get the below posted exception. I guess it is a problem with incompatibility of the libaries or possible the wrong order of the libraries. My classpath looks like this. /home/mkamp/lib/ant.jar:/home/mkamp/lib/batik-awt-util.jar:/home/mkamp/lib/batik-bridge.jar:/home/mkamp/lib/batik-css.jar:/home/mkamp/lib/batik-dom.jar:/home/mkamp/lib/batik-ext.jar:/home/mkamp/lib/batik-gui-util.jar:/home/mkamp/lib/batik-gvt.jar:/home/mkamp/lib/batik-parser.jar:/home/mkamp/lib/batik-script.jar:/home/mkamp/lib/batik-svg-dom.jar:/home/mkamp/lib/batik-svggen.jar:/home/mkamp/lib/batik-transcoder.jar:/home/mkamp/lib/batik-util.jar:/home/mkamp/lib/batik-xml.jar:/home/mkamp/lib/bsf.jar:/home/mkamp/lib/fop.jar:/home/mkamp/lib/jakarta-ant-1.3-optional.jar:/home/mkamp/lib/jakarta-regexp-1.3-dev.jar:/home/mkamp/lib/jcert.jar:/home/mkamp/lib/jmxgrinder.jar:/home/mkamp/lib/jmxri.jar:/home/mkamp/lib/jmxtools.jar:/home/mkamp/lib/jnet.jar:/home/mkamp/lib/jsse.jar:/home/mkamp/lib/junit.jar:/home/mkamp/lib/log4j-core.jar:/home/mkamp/lib/oracleClasses12.jar:/home/mkamp/lib/servlet.jar:/home/mkamp/lib/xalan122.jar:/home/mkamp/lib/xalan2.jar:/home/mkamp/lib/xerces.jar:/home/mkamp/lib/zservlet.jar:/home/mkamp/lib/zw3c.jar - Root Cause - java.lang.NoSuchMethodError: org.w3c.dom.css.CSSValue: method getCssValueType()S not found at org.apache.batik.bridge.CSSUtilities.convertVisibility(CSSUtilities.java:283) at org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(SVGSVGElementBridge.java:49) at org.apache.batik.bridge.ConcreteGVTBuilder.build(ConcreteGVTBuilder.java:78) at org.apache.batik.transcoder.image.ImageTranscoder.transcode(ImageTranscoder.java:190) at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(XMLAbstractTranscoder.java:122) at org.apache.cocoon.serialization.SVGSerializer.notify(SVGSerializer.java:210) at org.apache.cocoon.xml.dom.SVGBuilder.endDocument(SVGBuilder.java:107) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:51) at org.apache.cocoon.xml.dom.DOMStreamer.setDocument(DOMStreamer.java:153) at org.apache.cocoon.xml.dom.DOMStreamer.processNode(DOMStreamer.java:98) at org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:84) at org.apache.cocoon.generation.FragmentExtractorGenerator.generate(FragmentExtractorGenerator.java:103) at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:221) at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:345) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1790) at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1392) at org.apache.cocoon.sitemap.Handler.process(Handler.java:159) at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:97) at org.apache.cocoon.Cocoon.process(Cocoon.java:288) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:442) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:254) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at
[jira] Closed: (COCOON-7) Oracle Support in build.xml
[ http://issues.apache.org/jira/browse/COCOON-7?page=all ] Helma van der Linden closed COCOON-7: - Resolution: Fixed closed with resolution = fixed Oracle Support in build.xml --- Key: COCOON-7 URL: http://issues.apache.org/jira/browse/COCOON-7 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Alpha Environment: Operating System: Linux Platform: PC Reporter: mkamp Priority: Minor After running ANT I get the below posted error message. Before that it is checked in the build.xml if a particular oracle class is present. This class seems to be present on my system. Nevertheless oracle.jdbc.OracleResultSet is not present on my system but referenced. I can work around with removing the test for oracle, so that everything is compiled without the oracle support. Mariano compile: [copy] Copying 1 file to /home/mkamp/xml-cocoon/build/cocoon/classes [javac] Compiling 3 source files to /home/mkamp/xml-cocoon/build/cocoon/classes [javac] /home/mkamp/xml-cocoon/build/cocoon/src/org/apache/cocoon/acting/OraAddAction.java:24: Class oracle.jdbc.OracleResultSet not found in import. [javac] import oracle.jdbc.OracleResultSet; [javac]^ [javac] 1 error BUILD FAILED /home/mkamp/xml-cocoon/build.xml:312: Compile failed, messages should have been provided. -- 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] Reopened: (COCOON-34) JspGenerator doesn't allow relative src
[ http://issues.apache.org/jira/browse/COCOON-34?page=all ]
Helma van der Linden reopened COCOON-34:
reopened just to set the resolution to fixed
JspGenerator doesn't allow relative src
---
Key: COCOON-34
URL: http://issues.apache.org/jira/browse/COCOON-34
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.0 Alpha
Environment: Operating System: other
Platform: Other
Reporter: Sergio Carvalho
Assignee: Cocoon Developers Team
When the JspGenerator src parameter is a path relative to the current sitemap
context, the generator will fail, producing a
org.apache.jasper.JasperException: Unable to compile class for JSP
To reproduce:
* Remove the leading slash from the JSP sample pipeline src parameter. It
becomes:
map:match pattern=jsp/*
map:generate type=jsp src=docs/samples/jsp/{1}.jsp/
map:transform src=stylesheets/page/simple-page2html.xsl/
map:serialize type=html/
/map:match
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-38) Action in sub-sitemap re-directing using parent sitemap
[ http://issues.apache.org/jira/browse/COCOON-38?page=all ]
Helma van der Linden reopened COCOON-38:
reopened just to set the resolution to fixed
Action in sub-sitemap re-directing using parent sitemap
---
Key: COCOON-38
URL: http://issues.apache.org/jira/browse/COCOON-38
Project: Cocoon
Type: Bug
Components: - Components: Sitemap
Versions: 2.0 Beta 1
Environment: Operating System: Linux
Platform: PC
Reporter: Rick Tessner
Assignee: Cocoon Developers Team
I'm playing around with actions and I'm finding rather odd behaviour
when they're used in sub-sitemaps. The main sitemap.xmap is that
which comes with Cocoon2 out of CVS. I've added the following
pipeline to that sitemap.xmap:
map:pipeline
map:match type=regexp pattern=^~([^/]*)
map:mount uri-prefix=~{1} src=/home/{1}/public_xml/
check-reload=yes/
/map:match
/map:pipeline
This means that a URL like http://localhost/cocoon/~rick/... will
go and look at the sitemap in /home/rick/public_xml/sitemap.xmap.
This all works fine.
In the /home/rick/public_xml/sitemap.xmap I have something like
this:
map:match pattern=
map:act type=hello-action
map:generate src=index.xml/
map:transform
src=/home/rick/projects/stylesheets/xsl/index-html.xsl/
map:serialize type=html/
/map:act
/map:match
First, without the map:act, /map:act everything works just wonderfully.
The index.xml is transformed using the index-html.xsl transformation
sheet.
As soon as I put in the hello-action action, my URL gets re-written
to be
http://localhost/cocoon/~rick/welcome
from the original
http://localhost/cocoon/~rick/
The re-writing appears to be done in the main sitemap. The main
sitemap has a map:match like:
map:match pattern=
map:redirect-to uri=welcome/
/map:match
It appears that this matcher in the parent sitemap.xmap is being
used after the action in my sub-sitemap has completed.
The hello-action is just using the org.apache.cocoon.acting.HelloAction
class that comes with cocoon2. The action itself is defined in
the sub-sitemap as:
map:actions
map:action name=hello-action
src=org.apache.cocoon.acting.HelloAction/
/map:actions
--
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] Reopened: (COCOON-44) XSLT not working when generating with own generator from file
[ http://issues.apache.org/jira/browse/COCOON-44?page=all ] Helma van der Linden reopened COCOON-44: reopened just to set the resolution to fixed XSLT not working when generating with own generator from file - Key: COCOON-44 URL: http://issues.apache.org/jira/browse/COCOON-44 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0 Beta 1 Environment: Operating System: All Platform: All Reporter: kavalar Assignee: Cocoon Developers Team Priority: Critical The page is using its own generator which uses several xml sources (Some are compiled into the Generator in Java, the Navigation is sent from a file on the FS to the XMLConsumer, the sidebox is a RTF read over http). The default XML includes the navigation: http://cinter.jintelligence.com:8080/mux/muxml the xml without the navigation looks like this: http://cinter.jintelligence.com:8080/mux/muxml?nav=0 Now if the whole xml is tranformed i get this output: http://cinter.jintelligence.com:8080/mux/muxhtml Notice how the navigation AND the content in the middle is missing though it EXISTS when using Cooktop for the transformation. But the really odd thing is when you turn off the navigation http://cinter.jintelligence.com:8080/mux/muxhtml?nav=0 you DO get the content in the middle though it is on the same level as the navigation. How can they possibly affect each other? -- 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-34) JspGenerator doesn't allow relative src
[ http://issues.apache.org/jira/browse/COCOON-34?page=all ]
Helma van der Linden closed COCOON-34:
--
Resolution: Fixed
closed with resolution = fixed
JspGenerator doesn't allow relative src
---
Key: COCOON-34
URL: http://issues.apache.org/jira/browse/COCOON-34
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.0 Alpha
Environment: Operating System: other
Platform: Other
Reporter: Sergio Carvalho
Assignee: Cocoon Developers Team
When the JspGenerator src parameter is a path relative to the current sitemap
context, the generator will fail, producing a
org.apache.jasper.JasperException: Unable to compile class for JSP
To reproduce:
* Remove the leading slash from the JSP sample pipeline src parameter. It
becomes:
map:match pattern=jsp/*
map:generate type=jsp src=docs/samples/jsp/{1}.jsp/
map:transform src=stylesheets/page/simple-page2html.xsl/
map:serialize type=html/
/map:match
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-38) Action in sub-sitemap re-directing using parent sitemap
[ http://issues.apache.org/jira/browse/COCOON-38?page=all ]
Helma van der Linden closed COCOON-38:
--
Resolution: Fixed
closed with resolution = fixed
Action in sub-sitemap re-directing using parent sitemap
---
Key: COCOON-38
URL: http://issues.apache.org/jira/browse/COCOON-38
Project: Cocoon
Type: Bug
Components: - Components: Sitemap
Versions: 2.0 Beta 1
Environment: Operating System: Linux
Platform: PC
Reporter: Rick Tessner
Assignee: Cocoon Developers Team
I'm playing around with actions and I'm finding rather odd behaviour
when they're used in sub-sitemaps. The main sitemap.xmap is that
which comes with Cocoon2 out of CVS. I've added the following
pipeline to that sitemap.xmap:
map:pipeline
map:match type=regexp pattern=^~([^/]*)
map:mount uri-prefix=~{1} src=/home/{1}/public_xml/
check-reload=yes/
/map:match
/map:pipeline
This means that a URL like http://localhost/cocoon/~rick/... will
go and look at the sitemap in /home/rick/public_xml/sitemap.xmap.
This all works fine.
In the /home/rick/public_xml/sitemap.xmap I have something like
this:
map:match pattern=
map:act type=hello-action
map:generate src=index.xml/
map:transform
src=/home/rick/projects/stylesheets/xsl/index-html.xsl/
map:serialize type=html/
/map:act
/map:match
First, without the map:act, /map:act everything works just wonderfully.
The index.xml is transformed using the index-html.xsl transformation
sheet.
As soon as I put in the hello-action action, my URL gets re-written
to be
http://localhost/cocoon/~rick/welcome
from the original
http://localhost/cocoon/~rick/
The re-writing appears to be done in the main sitemap. The main
sitemap has a map:match like:
map:match pattern=
map:redirect-to uri=welcome/
/map:match
It appears that this matcher in the parent sitemap.xmap is being
used after the action in my sub-sitemap has completed.
The hello-action is just using the org.apache.cocoon.acting.HelloAction
class that comes with cocoon2. The action itself is defined in
the sub-sitemap as:
map:actions
map:action name=hello-action
src=org.apache.cocoon.acting.HelloAction/
/map:actions
--
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-44) XSLT not working when generating with own generator from file
[ http://issues.apache.org/jira/browse/COCOON-44?page=all ] Helma van der Linden closed COCOON-44: -- Resolution: Fixed closed with resolution = fixed XSLT not working when generating with own generator from file - Key: COCOON-44 URL: http://issues.apache.org/jira/browse/COCOON-44 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0 Beta 1 Environment: Operating System: All Platform: All Reporter: kavalar Assignee: Cocoon Developers Team Priority: Critical The page is using its own generator which uses several xml sources (Some are compiled into the Generator in Java, the Navigation is sent from a file on the FS to the XMLConsumer, the sidebox is a RTF read over http). The default XML includes the navigation: http://cinter.jintelligence.com:8080/mux/muxml the xml without the navigation looks like this: http://cinter.jintelligence.com:8080/mux/muxml?nav=0 Now if the whole xml is tranformed i get this output: http://cinter.jintelligence.com:8080/mux/muxhtml Notice how the navigation AND the content in the middle is missing though it EXISTS when using Cooktop for the transformation. But the really odd thing is when you turn off the navigation http://cinter.jintelligence.com:8080/mux/muxhtml?nav=0 you DO get the content in the middle though it is on the same level as the navigation. How can they possibly affect each other? -- 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] Reopened: (COCOON-48) Volume-Name SYS: becomes protocol on Novell Netware
[ http://issues.apache.org/jira/browse/COCOON-48?page=all ] Helma van der Linden reopened COCOON-48: reopened just to set the resolution to fixed Volume-Name SYS: becomes protocol on Novell Netware --- Key: COCOON-48 URL: http://issues.apache.org/jira/browse/COCOON-48 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3 Environment: Operating System: other Platform: PC Reporter: Björn Willnus Assignee: Cocoon Developers Team We tried to install Cocoon 2.0b2 on an existing Tomcat-Installation, running on a Novell-Fileserver with Apache 1.3.20. Tomcat-Path is something like: SYS:\apache\tomcat It seems that Cocoon tries to build an uri with sys: as a protocol instead of http: -- 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-48) Volume-Name SYS: becomes protocol on Novell Netware
[ http://issues.apache.org/jira/browse/COCOON-48?page=all ] Helma van der Linden closed COCOON-48: -- Resolution: Fixed closed with resolution = fixed Volume-Name SYS: becomes protocol on Novell Netware --- Key: COCOON-48 URL: http://issues.apache.org/jira/browse/COCOON-48 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.3 Environment: Operating System: other Platform: PC Reporter: Björn Willnus Assignee: Cocoon Developers Team We tried to install Cocoon 2.0b2 on an existing Tomcat-Installation, running on a Novell-Fileserver with Apache 1.3.20. Tomcat-Path is something like: SYS:\apache\tomcat It seems that Cocoon tries to build an uri with sys: as a protocol instead of http: -- 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] Reopened: (COCOON-93) cocoon hangs trying to load the sample pages
[ http://issues.apache.org/jira/browse/COCOON-93?page=all ] Helma van der Linden reopened COCOON-93: reopened just to set the resolution to fixed cocoon hangs trying to load the sample pages Key: COCOON-93 URL: http://issues.apache.org/jira/browse/COCOON-93 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Environment: Operating System: Solaris Platform: Sun Reporter: Christian Hardmeier Assignee: Cocoon Developers Team Priority: Critical Cocoon build process completes with no errors (though I have to use bash rather than /bin/sh for the bin/ant script - build.sh works with /bin/sh now). As soon as I try to access any page within the Cocoon webapp (using the sample pages as delivered), the request is processed up to a certain point, then hangs infinitely (log see below). When I comment out all the svg-related parts of sitemap.xmap, access to the index page works, however most of the other parts still don't, notably the documentation and the XSP samples. Here is some information on the system and the incident, I'll be happy to provide any other details you might find relevant. Environment: Solaris 8 (7/01), Sparc Tomcat 4.0.1 Cocoon 2.0 (same problem already with Cocoon 2.0rc2) More exactly: quidam:~$ uname -a SunOS quidam 5.8 Generic_108528-09 sun4u sparc SUNW,Sun-Blade-100 quidam:~$ java -version java version 1.3.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01) Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) (I also tried v1.3.0 of Java, with no success) Last lines in cocoon.log.01 with no changes to the sitemap: DEBUG (2001-11-30) 16:27.05:927 [cocoon ] (/cocoon/status) Thread-17/Defaul tComponentFactory: ComponentFactory creating new instance of org.apache.cocoon.s erialization.XMLSerializer. DEBUG (2001-11-30) 16:27.05:927 [cocoon ] (/cocoon/status) Thread-17/Defaul tComponentFactory: no logger attribute available, using standard logger DEBUG (2001-11-30) 16:27.05:928 [cocoon ] (/cocoon/status) Thread-17/Poolab leComponentHandler: ComponentHandler initialized for: org.apache.cocoon.serializ ation.XMLSerializer DEBUG (2001-11-30) 16:27.05:929 [cocoon ] (/cocoon/status) Thread-17/Excali burComponentSelector: Adding org.apache.cocoon.serialization.XMLSerializer for s vgxml last lines with svg parts of sitemap removed: DEBUG (2001-11-30) 16:45.15:718 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/DefaultComponentFactory: ComponentFactory creating new inst ance of org.apache.cocoon.serialization.LinkSerializer. DEBUG (2001-11-30) 16:45.15:718 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/DefaultComponentFactory: no logger attribute available, usi ng standard logger DEBUG (2001-11-30) 16:45.15:719 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/PoolableComponentHandler: ComponentHandler initialized for: org.apache.cocoon.serialization.LinkSerializer DEBUG (2001-11-30) 16:45.15:719 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/ExcaliburComponentSelector: Adding org.apache.cocoon.serial ization.LinkSerializer for links -- 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-93) cocoon hangs trying to load the sample pages
[ http://issues.apache.org/jira/browse/COCOON-93?page=all ] Helma van der Linden closed COCOON-93: -- Resolution: Fixed closed with resolution = fixed cocoon hangs trying to load the sample pages Key: COCOON-93 URL: http://issues.apache.org/jira/browse/COCOON-93 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Environment: Operating System: Solaris Platform: Sun Reporter: Christian Hardmeier Assignee: Cocoon Developers Team Priority: Critical Cocoon build process completes with no errors (though I have to use bash rather than /bin/sh for the bin/ant script - build.sh works with /bin/sh now). As soon as I try to access any page within the Cocoon webapp (using the sample pages as delivered), the request is processed up to a certain point, then hangs infinitely (log see below). When I comment out all the svg-related parts of sitemap.xmap, access to the index page works, however most of the other parts still don't, notably the documentation and the XSP samples. Here is some information on the system and the incident, I'll be happy to provide any other details you might find relevant. Environment: Solaris 8 (7/01), Sparc Tomcat 4.0.1 Cocoon 2.0 (same problem already with Cocoon 2.0rc2) More exactly: quidam:~$ uname -a SunOS quidam 5.8 Generic_108528-09 sun4u sparc SUNW,Sun-Blade-100 quidam:~$ java -version java version 1.3.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01) Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) (I also tried v1.3.0 of Java, with no success) Last lines in cocoon.log.01 with no changes to the sitemap: DEBUG (2001-11-30) 16:27.05:927 [cocoon ] (/cocoon/status) Thread-17/Defaul tComponentFactory: ComponentFactory creating new instance of org.apache.cocoon.s erialization.XMLSerializer. DEBUG (2001-11-30) 16:27.05:927 [cocoon ] (/cocoon/status) Thread-17/Defaul tComponentFactory: no logger attribute available, using standard logger DEBUG (2001-11-30) 16:27.05:928 [cocoon ] (/cocoon/status) Thread-17/Poolab leComponentHandler: ComponentHandler initialized for: org.apache.cocoon.serializ ation.XMLSerializer DEBUG (2001-11-30) 16:27.05:929 [cocoon ] (/cocoon/status) Thread-17/Excali burComponentSelector: Adding org.apache.cocoon.serialization.XMLSerializer for s vgxml last lines with svg parts of sitemap removed: DEBUG (2001-11-30) 16:45.15:718 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/DefaultComponentFactory: ComponentFactory creating new inst ance of org.apache.cocoon.serialization.LinkSerializer. DEBUG (2001-11-30) 16:45.15:718 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/DefaultComponentFactory: no logger attribute available, usi ng standard logger DEBUG (2001-11-30) 16:45.15:719 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/PoolableComponentHandler: ComponentHandler initialized for: org.apache.cocoon.serialization.LinkSerializer DEBUG (2001-11-30) 16:45.15:719 [cocoon ] (/cocoon/documents/index.html) Ht tpProcessor[4505][1]/ExcaliburComponentSelector: Adding org.apache.cocoon.serial ization.LinkSerializer for links -- 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-66) Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver
[ http://issues.apache.org/jira/browse/COCOON-66?page=all ] Helma van der Linden closed COCOON-66: -- Resolution: Fixed closed with resolution = fixed Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver --- Key: COCOON-66 URL: http://issues.apache.org/jira/browse/COCOON-66 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Release Candidate 1 Environment: Operating System: All Platform: PC Reporter: Henric Böhm Assignee: Cocoon Developers Team Attachments: Internal servlet error.htm, cocoon.log.01, cocoon.log.01, root.log.01 INFO: Beforehand I would still like to say something so that again many annoyed answers don't come back: I know that there is no support for other system. Maybe however, the mistake- news can help nevertheless further. INFO: I have tried Cocoon2 RC1 on the In-Q-My Web application servers 4.2.7. to installed. BAD: Seems to me with it that when initializing Cocoon the information over the configuration-data file file:/ /localhost/C:/In-Q- MyAppServer4.2.7/alone\services\servlet_jsp\work\jspTemp\cocoon\root\cocoon.xcon f loses, although the data file participates attainable under this URL. At the beginning, the roles will finish reading all right and then all at once the resolver is found no longer. INFO: Further information under: www.inqmy.com GOOD: Incidentally, I have no problems with the same installation on the Tomcat 4 at all. -- 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] Reopened: (COCOON-66) Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver
[ http://issues.apache.org/jira/browse/COCOON-66?page=all ] Helma van der Linden reopened COCOON-66: reopened just to set the resolution to fixed Error in JaxpParser: Cannot find org.apache.cocoon.components.resolver.Resolver --- Key: COCOON-66 URL: http://issues.apache.org/jira/browse/COCOON-66 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Release Candidate 1 Environment: Operating System: All Platform: PC Reporter: Henric Böhm Assignee: Cocoon Developers Team Attachments: Internal servlet error.htm, cocoon.log.01, cocoon.log.01, root.log.01 INFO: Beforehand I would still like to say something so that again many annoyed answers don't come back: I know that there is no support for other system. Maybe however, the mistake- news can help nevertheless further. INFO: I have tried Cocoon2 RC1 on the In-Q-My Web application servers 4.2.7. to installed. BAD: Seems to me with it that when initializing Cocoon the information over the configuration-data file file:/ /localhost/C:/In-Q- MyAppServer4.2.7/alone\services\servlet_jsp\work\jspTemp\cocoon\root\cocoon.xcon f loses, although the data file participates attainable under this URL. At the beginning, the roles will finish reading all right and then all at once the resolver is found no longer. INFO: Further information under: www.inqmy.com GOOD: Incidentally, I have no problems with the same installation on the Tomcat 4 at all. -- 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] Reopened: (COCOON-125) Java SecurityManager java.lang.RuntimePermission createSecurityManager required for cocoon 2
[ http://issues.apache.org/jira/browse/COCOON-125?page=all ] Helma van der Linden reopened COCOON-125: - reopened just to set the resolution to fixed Java SecurityManager java.lang.RuntimePermission createSecurityManager required for cocoon 2 Key: COCOON-125 URL: http://issues.apache.org/jira/browse/COCOON-125 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Environment: Operating System: All Platform: All Reporter: Glenn Nielsen Assignee: Cocoon Developers Team The class org.apache.cocoon.util.log.CocoonLogFormatter$CallStack extends java.lang.SecurityManager. The comments for this class indicate that this is a hack to get a stack trace as an array of classses. But if you are running Cocoon 2 in a servlet container such as Tomcat with the Java SecurityManager enabled this requires that you grant the java.lang.RuntimePermission createSecurityManager to cocoon in your policy file This is a dangerous permission to grant. This needs to be changed so that extending java.lang.SecurityManager is not needed. -- 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-125) Java SecurityManager java.lang.RuntimePermission createSecurityManager required for cocoon 2
[ http://issues.apache.org/jira/browse/COCOON-125?page=all ] Helma van der Linden closed COCOON-125: --- Resolution: Fixed closed with resolution = fixed Java SecurityManager java.lang.RuntimePermission createSecurityManager required for cocoon 2 Key: COCOON-125 URL: http://issues.apache.org/jira/browse/COCOON-125 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0 Environment: Operating System: All Platform: All Reporter: Glenn Nielsen Assignee: Cocoon Developers Team The class org.apache.cocoon.util.log.CocoonLogFormatter$CallStack extends java.lang.SecurityManager. The comments for this class indicate that this is a hack to get a stack trace as an array of classses. But if you are running Cocoon 2 in a servlet container such as Tomcat with the Java SecurityManager enabled this requires that you grant the java.lang.RuntimePermission createSecurityManager to cocoon in your policy file This is a dangerous permission to grant. This needs to be changed so that extending java.lang.SecurityManager is not needed. -- 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] Reopened: (COCOON-131) JSP transform problem
[ http://issues.apache.org/jira/browse/COCOON-131?page=all ]
Helma van der Linden reopened COCOON-131:
-
reopened just to set the resolution to fixed
JSP transform problem
-
Key: COCOON-131
URL: http://issues.apache.org/jira/browse/COCOON-131
Project: Cocoon
Type: Bug
Components: - Components: Avalon
Versions: 2.0
Environment: Operating System: Linux
Platform: PC
Reporter: alan ho
Assignee: Cocoon Developers Team
I use tomcat as my serlet engine.I plan to use JSP-XML-XSLT-HTML to
construct a web app.
I have add the following to my root sitemap.xmap
---
map:pipeline
map:match pattern=jsp/**
map:mount uri-prefix=jsp src=j/ check-reload=yes/
/map:match
/map:pipeline
And write a simple sitemap.xmap at j/
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
!-- === Components
--
map:components
map:generators default=file/
map:transformers default=xslt/
map:readers default=resource/
map:serializers default=html/
map:selectors default=browser/
map:matchers default=wildcard/
/map:components
!-- === Pipelines =
--
map:pipelines
map:pipeline
map:match pattern=*.jsp
map:generate type=jsp src={1}.jsp/
map:transform src=../stylesheets/sites/htmlbasepage.xsl/
map:serialize/
/map:match
map:match pattern=*.xml
map:generate src={1}.xml/
map:transform src=../stylesheets/sites/htmlbasepage.xsl/
map:serialize/
/map:match
map:handle-errors
map:transform src=../stylesheets/system/error2html.xsl/
map:serialize status-code=500/
/map:handle-errors
/map:pipeline
/map:pipelines
/map:sitemap
!-- end of file --
Then I write a simple page(test.jsp) and make it a symbolic to test.html.
-
page
titleWelcome to Login/title
menu
/menu
main
/main
footer
copyrightOwned by Hibit/copyright
/footer
login-table/
/page
When I browse http://localhost:8081/cocoon/j/test.html,cocoon works fine to
transform the page to a html file.
Then I browse http://localhost:8081/cocoon/j/test.jsp,cocoon fails to
transform
the page to html.Cocoon generates a original page as I typed.The transformer
has broken!
Does anybody know what's going wrong?
--
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-131) JSP transform problem
[ http://issues.apache.org/jira/browse/COCOON-131?page=all ]
Helma van der Linden closed COCOON-131:
---
Resolution: Fixed
closed with resolution = fixed
JSP transform problem
-
Key: COCOON-131
URL: http://issues.apache.org/jira/browse/COCOON-131
Project: Cocoon
Type: Bug
Components: - Components: Avalon
Versions: 2.0
Environment: Operating System: Linux
Platform: PC
Reporter: alan ho
Assignee: Cocoon Developers Team
I use tomcat as my serlet engine.I plan to use JSP-XML-XSLT-HTML to
construct a web app.
I have add the following to my root sitemap.xmap
---
map:pipeline
map:match pattern=jsp/**
map:mount uri-prefix=jsp src=j/ check-reload=yes/
/map:match
/map:pipeline
And write a simple sitemap.xmap at j/
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
!-- === Components
--
map:components
map:generators default=file/
map:transformers default=xslt/
map:readers default=resource/
map:serializers default=html/
map:selectors default=browser/
map:matchers default=wildcard/
/map:components
!-- === Pipelines =
--
map:pipelines
map:pipeline
map:match pattern=*.jsp
map:generate type=jsp src={1}.jsp/
map:transform src=../stylesheets/sites/htmlbasepage.xsl/
map:serialize/
/map:match
map:match pattern=*.xml
map:generate src={1}.xml/
map:transform src=../stylesheets/sites/htmlbasepage.xsl/
map:serialize/
/map:match
map:handle-errors
map:transform src=../stylesheets/system/error2html.xsl/
map:serialize status-code=500/
/map:handle-errors
/map:pipeline
/map:pipelines
/map:sitemap
!-- end of file --
Then I write a simple page(test.jsp) and make it a symbolic to test.html.
-
page
titleWelcome to Login/title
menu
/menu
main
/main
footer
copyrightOwned by Hibit/copyright
/footer
login-table/
/page
When I browse http://localhost:8081/cocoon/j/test.html,cocoon works fine to
transform the page to a html file.
Then I browse http://localhost:8081/cocoon/j/test.jsp,cocoon fails to
transform
the page to html.Cocoon generates a original page as I typed.The transformer
has broken!
Does anybody know what's going wrong?
--
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] Reopened: (COCOON-155) [PATCH] new powered by Cocoon bitmap
[ http://issues.apache.org/jira/browse/COCOON-155?page=all ] Helma van der Linden reopened COCOON-155: - reopened just to set the resolution to fixed [PATCH] new powered by Cocoon bitmap -- Key: COCOON-155 URL: http://issues.apache.org/jira/browse/COCOON-155 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Nicola Ken Barozzi Assignee: Cocoon Developers Team Priority: Minor Attachments: build-with-with-cocoon1.png, build-with-with-cocoon2.png, build-with-with-cocoon3.png, built-with-cocoon.png, cocoon2.gif, made-with-cocoon.png A new version of src/documentation/images/cocoon2-small.jpg that sucks a bit less. Why don't we add it to each site page? xml.apache.org/cocoon/ and Avalon *are* powered by Cocoon. -- 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] Reopened: (COCOON-157) Can't start first time (tomcat 4.0.2)
[ http://issues.apache.org/jira/browse/COCOON-157?page=all ] Helma van der Linden reopened COCOON-157: - reopened just to set the resolution to fixed Can't start first time (tomcat 4.0.2) - Key: COCOON-157 URL: http://issues.apache.org/jira/browse/COCOON-157 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.1 Environment: Operating System: Solaris Platform: Sun Reporter: Iouri Michtchenko Assignee: Cocoon Developers Team I downloaded http://xml.apache.org/cocoon/dist/cocoon-2.0.1-bin.zip and put cocoon.war file into tomcat/webapps. When I try to access it throws an exception with root cause : java.lang.NoClassDefFoundError: javax/xml/transform/URIResolver at java.lang.ClassLoader.findLoadedClass(Native Method) at java.lang.ClassLoader.findLoadedClass(Compiled Code) at org.apache.catalina.loader.WebappClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure (Compiled Code) at org.apache.cocoon.Cocoon.configure(Cocoon.java:406) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:267) at org.apache.cocoon.servlet.CocoonServlet.createCocoon (CocoonServlet.java:991) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:308) at org.apache.catalina.core.StandardWrapper.loadServlet(Compiled Code) at org.apache.catalina.core.StandardWrapper.allocate(Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardContext.invoke(Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.ErrorReportValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.AccessLogValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardEngineValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.connector.http.HttpProcessor.process(Compiled Code) at org.apache.catalina.connector.http.HttpProcessor.run(Compiled Code) at java.lang.Thread.run(Compiled Code) -- 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-155) [PATCH] new powered by Cocoon bitmap
[ http://issues.apache.org/jira/browse/COCOON-155?page=all ] Helma van der Linden closed COCOON-155: --- Resolution: Fixed closed with resolution = fixed [PATCH] new powered by Cocoon bitmap -- Key: COCOON-155 URL: http://issues.apache.org/jira/browse/COCOON-155 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Nicola Ken Barozzi Assignee: Cocoon Developers Team Priority: Minor Attachments: build-with-with-cocoon1.png, build-with-with-cocoon2.png, build-with-with-cocoon3.png, built-with-cocoon.png, cocoon2.gif, made-with-cocoon.png A new version of src/documentation/images/cocoon2-small.jpg that sucks a bit less. Why don't we add it to each site page? xml.apache.org/cocoon/ and Avalon *are* powered by Cocoon. -- 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-157) Can't start first time (tomcat 4.0.2)
[ http://issues.apache.org/jira/browse/COCOON-157?page=all ] Helma van der Linden closed COCOON-157: --- Resolution: Fixed closed with resolution = fixed Can't start first time (tomcat 4.0.2) - Key: COCOON-157 URL: http://issues.apache.org/jira/browse/COCOON-157 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.1 Environment: Operating System: Solaris Platform: Sun Reporter: Iouri Michtchenko Assignee: Cocoon Developers Team I downloaded http://xml.apache.org/cocoon/dist/cocoon-2.0.1-bin.zip and put cocoon.war file into tomcat/webapps. When I try to access it throws an exception with root cause : java.lang.NoClassDefFoundError: javax/xml/transform/URIResolver at java.lang.ClassLoader.findLoadedClass(Native Method) at java.lang.ClassLoader.findLoadedClass(Compiled Code) at org.apache.catalina.loader.WebappClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at java.lang.ClassLoader.loadClass(Compiled Code) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure (Compiled Code) at org.apache.cocoon.Cocoon.configure(Cocoon.java:406) at org.apache.cocoon.Cocoon.initialize(Cocoon.java:267) at org.apache.cocoon.servlet.CocoonServlet.createCocoon (CocoonServlet.java:991) at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:308) at org.apache.catalina.core.StandardWrapper.loadServlet(Compiled Code) at org.apache.catalina.core.StandardWrapper.allocate(Compiled Code) at org.apache.catalina.core.StandardWrapperValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardContextValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardContext.invoke(Compiled Code) at org.apache.catalina.core.StandardHostValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.ErrorReportValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.valves.AccessLogValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.core.StandardEngineValve.invoke(Compiled Code) at org.apache.catalina.core.StandardPipeline.invokeNext(Compiled Code) at org.apache.catalina.core.StandardPipeline.invoke(Compiled Code) at org.apache.catalina.core.ContainerBase.invoke(Compiled Code) at org.apache.catalina.connector.http.HttpProcessor.process(Compiled Code) at org.apache.catalina.connector.http.HttpProcessor.run(Compiled Code) at java.lang.Thread.run(Compiled Code) -- 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-190) sample jdbc connection fails under jdk 1.4
[ http://issues.apache.org/jira/browse/COCOON-190?page=all ] Helma van der Linden closed COCOON-190: --- Resolution: Fixed closed with resolution = fixed sample jdbc connection fails under jdk 1.4 -- Key: COCOON-190 URL: http://issues.apache.org/jira/browse/COCOON-190 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: Linux Platform: PC Reporter: Ryan Agler Assignee: Cocoon Developers Team When using the JDK 1.3, Cocoon starts up just fine. However, after switching to JDK 1.4, Cocoon shows the following errors in core.log: [core.datasources.personnel](Unknown-URI) Unknown-thread/LogKitLogger: factory created class was null so a new instance could not be created. org.apache.avalon.excalibur.datasource.NoValidConnectionException: No valid JdbcConnection class available This behavior exists with the sample connection and also a MySql connection which previously worked under JDK 1.3 -- 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-256) FormValidation fails because MapStackResolver.buildParameters(..) crashes
[ http://issues.apache.org/jira/browse/COCOON-256?page=all ] Helma van der Linden closed COCOON-256: --- Resolution: Fixed closed with resolution = fixed FormValidation fails because MapStackResolver.buildParameters(..) crashes - Key: COCOON-256 URL: http://issues.apache.org/jira/browse/COCOON-256 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: Windows XP Platform: PC Reporter: horu Assignee: Cocoon Developers Team In the tutorial sitemap: map:action-sets map:action-set name=process map:act type=form action=Create Department map:parameter name=validate-set value=add/ map:act type=dbAdd/ /map:act etc.. ..can't get processed because the MapStackResolver fails to resolve validate- set := add This seems to be a show stopper for formvalidation. WARN(2002-04-29) 10:07.08:999 [sitemap](/ba/tutorial/create-dept.html) HttpProcessor[8080][5]/PipelineNode: Error while processing pipeline at file:/C:/eclipseworkspace/test/webapp/tutorial/sitemap.xmap:84:17 java.lang.ClassCastException: java.lang.String at org.apache.cocoon.components.treeprocessor.MapStackResolver.buildParameters (MapStackResolver.java:160) at org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNode.call (ActionSetNode.java:158) at org.apache.cocoon.components.treeprocessor.sitemap.ActSetNode.invoke (ActSetNode.java:107) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:85) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:159) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:140) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:144) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:318) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:289) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:131) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:85) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:159) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:140) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:144) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:318) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:289) at org.apache.cocoon.Cocoon.process(Cocoon.java:588) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1002) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:190) ... -- 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] Reopened: (COCOON-256) FormValidation fails because MapStackResolver.buildParameters(..) crashes
[ http://issues.apache.org/jira/browse/COCOON-256?page=all ] Helma van der Linden reopened COCOON-256: - reopened just to set the resolution to fixed FormValidation fails because MapStackResolver.buildParameters(..) crashes - Key: COCOON-256 URL: http://issues.apache.org/jira/browse/COCOON-256 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: Windows XP Platform: PC Reporter: horu Assignee: Cocoon Developers Team In the tutorial sitemap: map:action-sets map:action-set name=process map:act type=form action=Create Department map:parameter name=validate-set value=add/ map:act type=dbAdd/ /map:act etc.. ..can't get processed because the MapStackResolver fails to resolve validate- set := add This seems to be a show stopper for formvalidation. WARN(2002-04-29) 10:07.08:999 [sitemap](/ba/tutorial/create-dept.html) HttpProcessor[8080][5]/PipelineNode: Error while processing pipeline at file:/C:/eclipseworkspace/test/webapp/tutorial/sitemap.xmap:84:17 java.lang.ClassCastException: java.lang.String at org.apache.cocoon.components.treeprocessor.MapStackResolver.buildParameters (MapStackResolver.java:160) at org.apache.cocoon.components.treeprocessor.sitemap.ActionSetNode.call (ActionSetNode.java:158) at org.apache.cocoon.components.treeprocessor.sitemap.ActSetNode.invoke (ActSetNode.java:107) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:85) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:159) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:140) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:144) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:318) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:289) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:131) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:85) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:159) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:140) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeN odes(AbstractParentProcessingNode.java:109) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:144) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:318) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:289) at org.apache.cocoon.Cocoon.process(Cocoon.java:588) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1002) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:190) ... -- 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] Reopened: (COCOON-267) Lucene index/search broken, wrong contentType each doc so ignored
[ http://issues.apache.org/jira/browse/COCOON-267?page=all ] Helma van der Linden reopened COCOON-267: - reopened just to set the resolution to fixed Lucene index/search broken, wrong contentType each doc so ignored - Key: COCOON-267 URL: http://issues.apache.org/jira/browse/COCOON-267 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: David Crossley Assignee: Cocoon Developers Team Christian Zoffoli wrote: I have just downloaded the last CVS ...and I have found that lucene cant do any search on the indexed pages. The indexing process seems to work fine but Index Statistics says Total Count of Documents 0. I looked at my core.log and found many entries like this ... - DEBUG (2002-05-04) 17:28.33:193 [core.search.lucene](/cocoon/search/create) HttpProcessor[8080][3]/SimpleLuceneXMLIndexerImpl: Ignoring http://localhost:8080/cocoon/documents/mail-archives.html?cocoon-view=content (text/html) - I see from the code that the Ignoring message arises when the contentType is null or not an allowed contentType. The code builds a small list of allowedContentType (xml, xhtml). CVS shows that the code and the samples pages have not changed for a while. So why would the contentType returned by cocoon-view have suddenly changed to be html? According to the sample/search/sitemap.xmap the cocoon-view=content does in fact serialise to xml. So why would the contentType be reporting as html? Perhaps there has been a change in that arena. --David -- 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] Reopened: (COCOON-291) CachingOutputStream doesn't handle severed connections
[ http://issues.apache.org/jira/browse/COCOON-291?page=all ] Helma van der Linden reopened COCOON-291: - reopened just to set the resolution to fixed CachingOutputStream doesn't handle severed connections -- Key: COCOON-291 URL: http://issues.apache.org/jira/browse/COCOON-291 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.4 Environment: Operating System: other Platform: All Reporter: Stuart Roebuck Assignee: Cocoon Developers Team If a file is being generated by the ResourceReader and an error occurs during transmission, because the connection is closed before the file is fully transmitted, then the exception is caught by ResourceReader and the CachingOutputStream returns the partial output as if it were complete. The next time the same resource is requested from the StreamCache, only the partial file is returned. This fault is present in 2.0.2 and still appears to be present in the new ProcessingPipeline code. If the CachingOutputStream could catch java.io.IOException: Broken pipe exceptions and continue to accept write calls until the stream has been completed (but not passing them to the 'receiver') this would ensure that the cache contained the complete file, even though the connection has been closed. -- 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-291) CachingOutputStream doesn't handle severed connections
[ http://issues.apache.org/jira/browse/COCOON-291?page=all ] Helma van der Linden closed COCOON-291: --- Resolution: Fixed closed with resolution = fixed CachingOutputStream doesn't handle severed connections -- Key: COCOON-291 URL: http://issues.apache.org/jira/browse/COCOON-291 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.4 Environment: Operating System: other Platform: All Reporter: Stuart Roebuck Assignee: Cocoon Developers Team If a file is being generated by the ResourceReader and an error occurs during transmission, because the connection is closed before the file is fully transmitted, then the exception is caught by ResourceReader and the CachingOutputStream returns the partial output as if it were complete. The next time the same resource is requested from the StreamCache, only the partial file is returned. This fault is present in 2.0.2 and still appears to be present in the new ProcessingPipeline code. If the CachingOutputStream could catch java.io.IOException: Broken pipe exceptions and continue to accept write calls until the stream has been completed (but not passing them to the 'receiver') this would ensure that the cache contained the complete file, even though the connection has been closed. -- 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] Reopened: (COCOON-298) [PATCH] CocoonServlet (init-classloader param)
[ http://issues.apache.org/jira/browse/COCOON-298?page=all ] Helma van der Linden reopened COCOON-298: - reopened just to set the resolution to fixed [PATCH] CocoonServlet (init-classloader param) -- Key: COCOON-298 URL: http://issues.apache.org/jira/browse/COCOON-298 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: David Haraburda Assignee: Cocoon Developers Team Attachments: CocoonServlet.java.dharaburda.patch CocoonServlet ignoes the init-classloader param in several places, setting the ContextClassLaoder to its own RepositoryClassLoader, causing JNDI not to work with Tomcat. This patch is intended to provide a temporary solution. Really, according to the Java API documentation, there shouldn't be the option of allowing Cocoon to create a classloader and override the container's. -- 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-298) [PATCH] CocoonServlet (init-classloader param)
[ http://issues.apache.org/jira/browse/COCOON-298?page=all ] Helma van der Linden closed COCOON-298: --- Resolution: Fixed closed with resolution = fixed [PATCH] CocoonServlet (init-classloader param) -- Key: COCOON-298 URL: http://issues.apache.org/jira/browse/COCOON-298 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: David Haraburda Assignee: Cocoon Developers Team Attachments: CocoonServlet.java.dharaburda.patch CocoonServlet ignoes the init-classloader param in several places, setting the ContextClassLaoder to its own RepositoryClassLoader, causing JNDI not to work with Tomcat. This patch is intended to provide a temporary solution. Really, according to the Java API documentation, there shouldn't be the option of allowing Cocoon to create a classloader and override the container's. -- 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-309) the cocoon:// protocoll allows no modular reuse
[ http://issues.apache.org/jira/browse/COCOON-309?page=all ] Helma van der Linden closed COCOON-309: --- Resolution: Fixed closed with resolution = fixed the cocoon:// protocoll allows no modular reuse - Key: COCOON-309 URL: http://issues.apache.org/jira/browse/COCOON-309 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: other Platform: Other Reporter: Maurice Schoenmakers Assignee: Cocoon Developers Team The bug prevents in general a modular reuse of a result of an existing sitemap into a new sitemap without having to change the original sitemap. Situation: 2 subdirectories /mount/A /mount/B, each with an own sitemap.xmap. In sitemap A we use the cocoon protocol: map:generate src=cocoon://mount/B/xyz / causes as an siteeffect an error that stylesheets/y.xsl can not be found for the following sitemap.xmap B: map:match pattern=xyz ... map:transform src=stylesheets/y.xsl/ map:serialize/ /map:match reason seams to be that the relative url =stylesheets/y.xsl of the transformer source in the sitemap B is not resolved relative to the directory of B but releative to the directory of A !!!. (PathInfo for the request of the cocoon: protocol is maybe wrong ???) (Only after writing an absolut context url in sitemap B the thing worked. This is a problem as it requires absolute urls every where and the path app B is hard coded in sitemap B ?!?!) -- 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] Reopened: (COCOON-309) the cocoon:// protocoll allows no modular reuse
[ http://issues.apache.org/jira/browse/COCOON-309?page=all ] Helma van der Linden reopened COCOON-309: - reopened just to set the resolution to fixed the cocoon:// protocoll allows no modular reuse - Key: COCOON-309 URL: http://issues.apache.org/jira/browse/COCOON-309 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: other Platform: Other Reporter: Maurice Schoenmakers Assignee: Cocoon Developers Team The bug prevents in general a modular reuse of a result of an existing sitemap into a new sitemap without having to change the original sitemap. Situation: 2 subdirectories /mount/A /mount/B, each with an own sitemap.xmap. In sitemap A we use the cocoon protocol: map:generate src=cocoon://mount/B/xyz / causes as an siteeffect an error that stylesheets/y.xsl can not be found for the following sitemap.xmap B: map:match pattern=xyz ... map:transform src=stylesheets/y.xsl/ map:serialize/ /map:match reason seams to be that the relative url =stylesheets/y.xsl of the transformer source in the sitemap B is not resolved relative to the directory of B but releative to the directory of A !!!. (PathInfo for the request of the cocoon: protocol is maybe wrong ???) (Only after writing an absolut context url in sitemap B the thing worked. This is a problem as it requires absolute urls every where and the path app B is hard coded in sitemap B ?!?!) -- 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-311) Nested actions in action-sets do not execute
[ http://issues.apache.org/jira/browse/COCOON-311?page=all ] Helma van der Linden closed COCOON-311: --- Resolution: Fixed closed with resolution = fixed Nested actions in action-sets do not execute Key: COCOON-311 URL: http://issues.apache.org/jira/browse/COCOON-311 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.8-dev (Current SVN) Environment: Operating System: Linux Platform: PC Reporter: Ivan Luzyanin Assignee: Cocoon Developers Team Priority: Blocker This bug affects Cocoon Tutorial (can't add a department or an employee). Example: map:action-set name=StoryEdit map:act action=Post Story type=form-validator map:parameter name=validate-set value=add/ map:act type=dbAdd/ !-- this action never executed -- /map:act /map:action-set -- 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] Reopened: (COCOON-311) Nested actions in action-sets do not execute
[ http://issues.apache.org/jira/browse/COCOON-311?page=all ] Helma van der Linden reopened COCOON-311: - reopened just to set the resolution to fixed Nested actions in action-sets do not execute Key: COCOON-311 URL: http://issues.apache.org/jira/browse/COCOON-311 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.8-dev (Current SVN) Environment: Operating System: Linux Platform: PC Reporter: Ivan Luzyanin Assignee: Cocoon Developers Team Priority: Blocker This bug affects Cocoon Tutorial (can't add a department or an employee). Example: map:action-set name=StoryEdit map:act action=Post Story type=form-validator map:parameter name=validate-set value=add/ map:act type=dbAdd/ !-- this action never executed -- /map:act /map:action-set -- 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] Reopened: (COCOON-328) Cannot set MIME type for ResourceReader
[ http://issues.apache.org/jira/browse/COCOON-328?page=all ] Helma van der Linden reopened COCOON-328: - reopened just to set the resolution to fixed Cannot set MIME type for ResourceReader --- Key: COCOON-328 URL: http://issues.apache.org/jira/browse/COCOON-328 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.3 Environment: Operating System: other Platform: Other Reporter: J.Pietschmann Assignee: Cocoon Developers Team The getMimeType gets the MIME type straight from the environment context, this is the servlet context for HTTP. This is somewhat surprising given that the sitemap for the Cocoon webapp contains entries like map:match pattern=cocoon.gif map:read mime-type=image/gif src=welcome/cocoon.gif/ /map:match The mime-type attribute here is completely ignored. I need a possibility to set the MIME type for a .jar reader to application/octet-stream, because Netscape4 interprets the MIME configured in Tomcat4 for .jar files, application/java-archive, as SmartUpdate, and this prevents users from downloading .jar files in certain circumstances. I suspect configuring JARs as application/octet-stream globally in Tomcat will interfere with applets, therefore I'd prefer a more local solution. -- 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-328) Cannot set MIME type for ResourceReader
[ http://issues.apache.org/jira/browse/COCOON-328?page=all ] Helma van der Linden closed COCOON-328: --- Resolution: Fixed closed with resolution = fixed Cannot set MIME type for ResourceReader --- Key: COCOON-328 URL: http://issues.apache.org/jira/browse/COCOON-328 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.3 Environment: Operating System: other Platform: Other Reporter: J.Pietschmann Assignee: Cocoon Developers Team The getMimeType gets the MIME type straight from the environment context, this is the servlet context for HTTP. This is somewhat surprising given that the sitemap for the Cocoon webapp contains entries like map:match pattern=cocoon.gif map:read mime-type=image/gif src=welcome/cocoon.gif/ /map:match The mime-type attribute here is completely ignored. I need a possibility to set the MIME type for a .jar reader to application/octet-stream, because Netscape4 interprets the MIME configured in Tomcat4 for .jar files, application/java-archive, as SmartUpdate, and this prevents users from downloading .jar files in certain circumstances. I suspect configuring JARs as application/octet-stream globally in Tomcat will interfere with applets, therefore I'd prefer a more local solution. -- 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-318) esql:update-results
[ http://issues.apache.org/jira/browse/COCOON-318?page=all ] Helma van der Linden closed COCOON-318: --- Resolution: Fixed closed with resolution = fixed esql:update-results - Key: COCOON-318 URL: http://issues.apache.org/jira/browse/COCOON-318 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0.3 Environment: Operating System: Linux Platform: PC Reporter: andi Assignee: Cocoon Developers Team nested esql query statement aren't executed in the new cocoon 2.0.3 version. this worked fine in version 2.0.2. example: esql:connection esql:poolpool/esql:pool esql:execute-query esql:query UPDATE xyz /esql:query esql:update-results esql:execute-query this nested statement won't be executed in 2.0.3 /esql:execute-query /esql:update-results /esql:execute-query /esql:connection -- 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] Reopened: (COCOON-318) esql:update-results
[ http://issues.apache.org/jira/browse/COCOON-318?page=all ] Helma van der Linden reopened COCOON-318: - reopened just to set the resolution to fixed esql:update-results - Key: COCOON-318 URL: http://issues.apache.org/jira/browse/COCOON-318 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0.3 Environment: Operating System: Linux Platform: PC Reporter: andi Assignee: Cocoon Developers Team nested esql query statement aren't executed in the new cocoon 2.0.3 version. this worked fine in version 2.0.2. example: esql:connection esql:poolpool/esql:pool esql:execute-query esql:query UPDATE xyz /esql:query esql:update-results esql:execute-query this nested statement won't be executed in 2.0.3 /esql:execute-query /esql:update-results /esql:execute-query /esql:connection -- 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] Reopened: (COCOON-337) Adding your own builtin-logicsheets does not work properly
[ http://issues.apache.org/jira/browse/COCOON-337?page=all ] Helma van der Linden reopened COCOON-337: - reopened just to set the resolution to fixed Adding your own builtin-logicsheets does not work properly -- Key: COCOON-337 URL: http://issues.apache.org/jira/browse/COCOON-337 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.2 Environment: Operating System: Linux Platform: PC Reporter: Matthias Brunner Assignee: Cocoon Developers Team Replaces Bug #10471 (description was not formatted properly) The bug description can be found at: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=102564324302908w=2 -- 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-337) Adding your own builtin-logicsheets does not work properly
[ http://issues.apache.org/jira/browse/COCOON-337?page=all ] Helma van der Linden closed COCOON-337: --- Resolution: Fixed closed with resolution = fixed Adding your own builtin-logicsheets does not work properly -- Key: COCOON-337 URL: http://issues.apache.org/jira/browse/COCOON-337 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.2 Environment: Operating System: Linux Platform: PC Reporter: Matthias Brunner Assignee: Cocoon Developers Team Replaces Bug #10471 (description was not formatted properly) The bug description can be found at: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=102564324302908w=2 -- 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] Reopened: (COCOON-371) [PATCH] Replacement for AvalonToCocoonSource
[ http://issues.apache.org/jira/browse/COCOON-371?page=all ] Helma van der Linden reopened COCOON-371: - reopened just to set the resolution to fixed [PATCH] Replacement for AvalonToCocoonSource Key: COCOON-371 URL: http://issues.apache.org/jira/browse/COCOON-371 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jens Lorenz Assignee: Cocoon Developers Team Priority: Minor Attachments: AbstractEnvironment.java, AvalonToCocoonSourceInvocationHandler.java The Source resolving invented for Cocoon was donated to Avalon-Excalibur. In order to maintain compatibility wrappers have been written. However this wrapping must fail as soon as there are some special Source Implementations which contain extended functionality. For example think of an ExtendedSource which might be used by FileGenerator for ordinary generation, but might also be used by ExtendedFileGenerator for extended generation. Obviously ExtendedFileGenerator has to check if the Source is actually an ExtendedSource and then call extended methods on it. The current AvalonToCocoonSource and CocoonToAvalonSource wrappers break this approach by not wrapping around the CocoonSource and then not allowing to access to wrapped source. A nice way to accomplish the same is by creating dynamic proxies (which are available from JDK 1.3 onwards). This class can implement any interface and then route the method call to another class. It can also be assigned to any interface it implements. The attachements contain a patched AbstractEnvironment (since it's there where the CocoonSources are wrapped) and an AvalonToCocoonSourceInvocationHandler which is needed for creating the proxy class and contains essentially the same logic as AvalonToCocoonSource. It shouldn't be hard to create a CocoonToAvalonSourceInvocationHandler on this basis for the other way around. The credits for creating this go to Stefan Köhler. -- 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] Reopened: (COCOON-391) DigesterTransformer donation
[ http://issues.apache.org/jira/browse/COCOON-391?page=all ] Helma van der Linden reopened COCOON-391: - reopened just to set the resolution to fixed DigesterTransformer donation Key: COCOON-391 URL: http://issues.apache.org/jira/browse/COCOON-391 Project: Cocoon Type: Improvement Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Michael Homeijer Assignee: Cocoon Developers Team Priority: Minor Attachments: DigesterCommand.java, DigesterTransformer.java See also http://jakarta.apache.org/commons/digester.html; --- Overview With the digester transformer it is possible to convert XML to Java classes. This does not apply only to data, but also applies to classes that perform functionality while they are created and their methods are called by the digester. By using factory- create-rule possibilities from the digester it is even possible to update and existing java class structure instead of only creating new java structures. Our primary use for it is to create a clean connection/seperation from a Cocoon front-end and an EJB back-end. - Configuration -- To use the DigesterTransformer in Cocoon, the jakarta commons digester has to be available in Cocoon (including the jars the digester depends upon). Declaration of the transformer component: map:transformer logger=sitemap.transformer.digester name=digester src=org.apache.cocoon.transformation.DigesterTransformer/ map:generate src=data.xml/ map:transform type=digester src=digester.xml map:parameter name=precommand value=... .transformation.helper.PrepareDigester/ map:parameter name=postcommand value=.. .transformation.helper.ProcessDigesterResult/ /map:transform The input for the transformer is XML data that must be transformed into java classes. The src attribute for the transformer specifies the xml rule input for the digester. The values specified in precommand and postcommand are classes that must implement org.apache.cocoon.transformation.helper.DigesterCommand - Note --- For now the transformer just outputs the input xml data. Additional data can be output in the sax stream with the use of the precommand and postcommand specification. Enjoy.. -- 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-401) [PATCH] SQLTransformer Query object prematurely closes connection causing NullPointerException when accessing ResultSet
[ http://issues.apache.org/jira/browse/COCOON-401?page=all ] Helma van der Linden closed COCOON-401: --- Resolution: Fixed [PATCH] SQLTransformer Query object prematurely closes connection causing NullPointerException when accessing ResultSet --- Key: COCOON-401 URL: http://issues.apache.org/jira/browse/COCOON-401 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.4 Environment: Operating System: All Platform: All Reporter: Brian Johnson Assignee: Cocoon Developers Team Attachments: SQLTransformer.patch, sqlproblem.txt The Query.execute() method closes the connection object after storing the ResultSet and ResultSetMetaData objects. This causes a NullPointerException when retrieving results from certain J2EE connections (FirebirdDS, possibly others). There is no reason for the conn.close() call as Query.close() closes everything and is called at the end of the SQLTransformer.executeQuery() method. Removing conn.close() and conn = null from the end of the Query.excute() method fixes the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (COCOON-401) [PATCH] SQLTransformer Query object prematurely closes connection causing NullPointerException when accessing ResultSet
[ http://issues.apache.org/jira/browse/COCOON-401?page=all ] Helma van der Linden reopened COCOON-401: - reopened just to set the resolution to fixed [PATCH] SQLTransformer Query object prematurely closes connection causing NullPointerException when accessing ResultSet --- Key: COCOON-401 URL: http://issues.apache.org/jira/browse/COCOON-401 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.0.4 Environment: Operating System: All Platform: All Reporter: Brian Johnson Assignee: Cocoon Developers Team Attachments: SQLTransformer.patch, sqlproblem.txt The Query.execute() method closes the connection object after storing the ResultSet and ResultSetMetaData objects. This causes a NullPointerException when retrieving results from certain J2EE connections (FirebirdDS, possibly others). There is no reason for the conn.close() call as Query.close() closes everything and is called at the end of the SQLTransformer.executeQuery() method. Removing conn.close() and conn = null from the end of the Query.excute() method fixes the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-391) DigesterTransformer donation
[ http://issues.apache.org/jira/browse/COCOON-391?page=all ] Helma van der Linden closed COCOON-391: --- Resolution: Fixed DigesterTransformer donation Key: COCOON-391 URL: http://issues.apache.org/jira/browse/COCOON-391 Project: Cocoon Type: Improvement Components: - Components: Sitemap Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Michael Homeijer Assignee: Cocoon Developers Team Priority: Minor Attachments: DigesterCommand.java, DigesterTransformer.java See also http://jakarta.apache.org/commons/digester.html; --- Overview With the digester transformer it is possible to convert XML to Java classes. This does not apply only to data, but also applies to classes that perform functionality while they are created and their methods are called by the digester. By using factory- create-rule possibilities from the digester it is even possible to update and existing java class structure instead of only creating new java structures. Our primary use for it is to create a clean connection/seperation from a Cocoon front-end and an EJB back-end. - Configuration -- To use the DigesterTransformer in Cocoon, the jakarta commons digester has to be available in Cocoon (including the jars the digester depends upon). Declaration of the transformer component: map:transformer logger=sitemap.transformer.digester name=digester src=org.apache.cocoon.transformation.DigesterTransformer/ map:generate src=data.xml/ map:transform type=digester src=digester.xml map:parameter name=precommand value=... .transformation.helper.PrepareDigester/ map:parameter name=postcommand value=.. .transformation.helper.ProcessDigesterResult/ /map:transform The input for the transformer is XML data that must be transformed into java classes. The src attribute for the transformer specifies the xml rule input for the digester. The values specified in precommand and postcommand are classes that must implement org.apache.cocoon.transformation.helper.DigesterCommand - Note --- For now the transformer just outputs the input xml data. Additional data can be output in the sax stream with the use of the precommand and postcommand specification. Enjoy.. -- 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] Reopened: (COCOON-410) RequestLifecycleComponents are not handled properly when the cocoon: protocol is used
[ http://issues.apache.org/jira/browse/COCOON-410?page=all ] Helma van der Linden reopened COCOON-410: - reopened just to set the resolution to fixed RequestLifecycleComponents are not handled properly when the cocoon: protocol is used - Key: COCOON-410 URL: http://issues.apache.org/jira/browse/COCOON-410 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Priority: Blocker RequestLifecycleComponents are not handled properly when the cocoon: protocol is used. This has many reasons, assume the following example: map:match pattern=mobiharzauth-** map:act type=auth-protect map:parameter name=handler value=portalhandler/ map:match pattern=mobiharzauth-portal-* map:generate src=cocoon:/mobiharzauth-loggedIn/ map:transform type=session/ map:serialize/ /map:match map:match pattern=mobiharzauth-loggedIn map:generate src=resources/auth/login.xml/ map:serialize/ /map:match /map:act /map:match When the first pipeline is called, it calls internally the second one - so far so good. The RequestLifecycleComponents are tied to the environment. When the first pipeline is executed, a AuthenticationManager is established for this and also an authentication manager for the second pipeline. But when the real XML streaming takes place, the second pipeline is execute, the toSAX() method of the SitemapSource to be exact. This changes the environment in order to run the internal pipeline - but as this environment is global this also changes the environment for the first pipeline and so the first pipeline cannot find the AuthenticationManager any more. PANG. But the problem is even worse. For an internal protocol the pipeline is established, and the enterEnvironment() events are send accordingly. When this generation of the pipeline is finished, the corresponding leaveEnvironments are called - so all RequestLifecycleComponents are destroyed at this time. But the XML is not streamed yet...so PANG again. The only solution is to rewrite all this stuff... Here is the XML: ?xml version=1.0? login xmlns:session=http://cocoon.apache.org/session/1.0; table tbody tr td phallo/p session:getxml context=authentication path=// /td /tr /tbody /table /login -- 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-421) [XMLFORM] java.lang.ArrayOutOfBoundsException
[ http://issues.apache.org/jira/browse/COCOON-421?page=all ] Helma van der Linden closed COCOON-421: --- Resolution: Fixed [XMLFORM] java.lang.ArrayOutOfBoundsException - Key: COCOON-421 URL: http://issues.apache.org/jira/browse/COCOON-421 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: James Snyder Assignee: Cocoon Developers Team Using both Xalan 2.3.1 and 2.4.0 or Saxon 6.5.2 with Xerces 2.1.0. I get the following stack trace when using the xmlform example wizard. I have seen this issue in past archives but there was no conclusive remedy. The initial panel comes up correctly, but when I try to transition, the exception occurs. Note that both incremental and non-incremental XSLT processor flags produce the same result. Original exception : java.lang.ArrayIndexOutOfBoundsException at org.apache.xml.utils.IntStack.pop(IntStack.java:127) at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.endElement(SAX2DTM.java:1785) at org.apache.xalan.transformer.TransformerHandlerImpl.endElement (TransformerHandlerImpl.java:549) at org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147) at org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147) at org.apache.cocoon.transformation.AbstractSAXTransformer.endElement (AbstractSAXTransformer.java:366) at org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:124) at org.apache.xerces.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement (XMLNamespaceBinder.java:898) at org.apache.xerces.impl.XMLNamespaceBinder.endElement (XMLNamespaceBinder.java:644) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1175) at org.apache.avalon.excalibur.xml.JaxpParser.parse(JaxpParser.java:264) at org.apache.avalon.excalibur.xml.JaxpParser.parse(JaxpParser.java:215) at org.apache.excalibur.xmlizer.impl.TextXMLizer.toSAX(TextXMLizer.java:44) at org.apache.excalibur.xmlizer.impl.AbstractXMLizer.toSAX (AbstractXMLizer.java:102) at org.apache.excalibur.xmlizer.impl.XMLizerImpl.toSAX(XMLizerImpl.java:94) at org.apache.cocoon.environment.AbstractEnvironment.toSAX (AbstractEnvironment.java:536) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.pro cessXMLPipeline(AbstractCachingProcessingPipeline.java:273) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:487) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke (SerializeNode.java:149) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke (ActTypeNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:107) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:153) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:107) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:150) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:326) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:131) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:162) at
[jira] Closed: (COCOON-410) RequestLifecycleComponents are not handled properly when the cocoon: protocol is used
[ http://issues.apache.org/jira/browse/COCOON-410?page=all ] Helma van der Linden closed COCOON-410: --- Resolution: Fixed RequestLifecycleComponents are not handled properly when the cocoon: protocol is used - Key: COCOON-410 URL: http://issues.apache.org/jira/browse/COCOON-410 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Priority: Blocker RequestLifecycleComponents are not handled properly when the cocoon: protocol is used. This has many reasons, assume the following example: map:match pattern=mobiharzauth-** map:act type=auth-protect map:parameter name=handler value=portalhandler/ map:match pattern=mobiharzauth-portal-* map:generate src=cocoon:/mobiharzauth-loggedIn/ map:transform type=session/ map:serialize/ /map:match map:match pattern=mobiharzauth-loggedIn map:generate src=resources/auth/login.xml/ map:serialize/ /map:match /map:act /map:match When the first pipeline is called, it calls internally the second one - so far so good. The RequestLifecycleComponents are tied to the environment. When the first pipeline is executed, a AuthenticationManager is established for this and also an authentication manager for the second pipeline. But when the real XML streaming takes place, the second pipeline is execute, the toSAX() method of the SitemapSource to be exact. This changes the environment in order to run the internal pipeline - but as this environment is global this also changes the environment for the first pipeline and so the first pipeline cannot find the AuthenticationManager any more. PANG. But the problem is even worse. For an internal protocol the pipeline is established, and the enterEnvironment() events are send accordingly. When this generation of the pipeline is finished, the corresponding leaveEnvironments are called - so all RequestLifecycleComponents are destroyed at this time. But the XML is not streamed yet...so PANG again. The only solution is to rewrite all this stuff... Here is the XML: ?xml version=1.0? login xmlns:session=http://cocoon.apache.org/session/1.0; table tbody tr td phallo/p session:getxml context=authentication path=// /td /tr /tbody /table /login -- 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] Reopened: (COCOON-438) [PATCH] Add a new logicsheet xsp-session-fw
[ http://issues.apache.org/jira/browse/COCOON-438?page=all ] Helma van der Linden reopened COCOON-438: - reopened just to set the resolution to fixed [PATCH] Add a new logicsheet xsp-session-fw --- Key: COCOON-438 URL: http://issues.apache.org/jira/browse/COCOON-438 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Antonio Gallardo Assignee: Antonio Gallardo Attachments: new_patch_13070.zip, new_patch_13070.zip, session-fw-patch.zip, xsp-patch.zip This new tag for xsp-session, features the same as session:getxml. It is intended to be used by XSP developers to get SessionContext data. I hope it will find its place into Cocoon 2.1 :) -- 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-430) Wrong handling of HTTP Headers
[ http://issues.apache.org/jira/browse/COCOON-430?page=all ] Helma van der Linden closed COCOON-430: --- Resolution: Fixed Wrong handling of HTTP Headers -- Key: COCOON-430 URL: http://issues.apache.org/jira/browse/COCOON-430 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Priority: Critical HTTP Headers are not handled correctly for Readers: When a binary content is queried the second time by the same client, the client usually sents the If-Modified-Since header. The HttpEnvironment compares this information with the last modification date of the source used for the reader. If this date comparisson is successful, Cocoon immediately returns to the client and no new generation takes place - because the browser has the content cached. This seems correct, but is actually dead wrong! This only works if the reader always reads the same src, but if the reader for example randomly chooses an image, the src does change but perhaps not the last modification date (if all srcs have the same last modification date for example - which is usual for deployed web applications). So the client always displays the image of the first request. -- 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] Reopened: (COCOON-421) [XMLFORM] java.lang.ArrayOutOfBoundsException
[ http://issues.apache.org/jira/browse/COCOON-421?page=all ] Helma van der Linden reopened COCOON-421: - reopened just to set the resolution to fixed [XMLFORM] java.lang.ArrayOutOfBoundsException - Key: COCOON-421 URL: http://issues.apache.org/jira/browse/COCOON-421 Project: Cocoon Type: Bug Components: - Components: Avalon Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: James Snyder Assignee: Cocoon Developers Team Using both Xalan 2.3.1 and 2.4.0 or Saxon 6.5.2 with Xerces 2.1.0. I get the following stack trace when using the xmlform example wizard. I have seen this issue in past archives but there was no conclusive remedy. The initial panel comes up correctly, but when I try to transition, the exception occurs. Note that both incremental and non-incremental XSLT processor flags produce the same result. Original exception : java.lang.ArrayIndexOutOfBoundsException at org.apache.xml.utils.IntStack.pop(IntStack.java:127) at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.endElement(SAX2DTM.java:1785) at org.apache.xalan.transformer.TransformerHandlerImpl.endElement (TransformerHandlerImpl.java:549) at org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147) at org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:147) at org.apache.cocoon.transformation.AbstractSAXTransformer.endElement (AbstractSAXTransformer.java:366) at org.apache.cocoon.components.sax.XMLTeePipe.endElement(XMLTeePipe.java:124) at org.apache.xerces.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:585) at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement (XMLNamespaceBinder.java:898) at org.apache.xerces.impl.XMLNamespaceBinder.endElement (XMLNamespaceBinder.java:644) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (XMLDocumentFragmentScannerImpl.java:1008) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(XMLDocumentFragmentScannerImpl.java:1469) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1175) at org.apache.avalon.excalibur.xml.JaxpParser.parse(JaxpParser.java:264) at org.apache.avalon.excalibur.xml.JaxpParser.parse(JaxpParser.java:215) at org.apache.excalibur.xmlizer.impl.TextXMLizer.toSAX(TextXMLizer.java:44) at org.apache.excalibur.xmlizer.impl.AbstractXMLizer.toSAX (AbstractXMLizer.java:102) at org.apache.excalibur.xmlizer.impl.XMLizerImpl.toSAX(XMLizerImpl.java:94) at org.apache.cocoon.environment.AbstractEnvironment.toSAX (AbstractEnvironment.java:536) at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.pro cessXMLPipeline(AbstractCachingProcessingPipeline.java:273) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process (AbstractProcessingPipeline.java:487) at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke (SerializeNode.java:149) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke (ActTypeNode.java:155) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke (PreparableMatchNode.java:162) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:107) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke (PipelineNode.java:153) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:107) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke (PipelinesNode.java:150) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:326) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:308) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke (MountNode.java:131) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNo des(AbstractParentProcessingNode.java:83) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke
[jira] Reopened: (COCOON-430) Wrong handling of HTTP Headers
[ http://issues.apache.org/jira/browse/COCOON-430?page=all ] Helma van der Linden reopened COCOON-430: - reopened just to set the resolution to fixed Wrong handling of HTTP Headers -- Key: COCOON-430 URL: http://issues.apache.org/jira/browse/COCOON-430 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.0.5-dev (Current CVS) Environment: Operating System: All Platform: All Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Priority: Critical HTTP Headers are not handled correctly for Readers: When a binary content is queried the second time by the same client, the client usually sents the If-Modified-Since header. The HttpEnvironment compares this information with the last modification date of the source used for the reader. If this date comparisson is successful, Cocoon immediately returns to the client and no new generation takes place - because the browser has the content cached. This seems correct, but is actually dead wrong! This only works if the reader always reads the same src, but if the reader for example randomly chooses an image, the src does change but perhaps not the last modification date (if all srcs have the same last modification date for example - which is usual for deployed web applications). So the client always displays the image of the first request. -- 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-438) [PATCH] Add a new logicsheet xsp-session-fw
[ http://issues.apache.org/jira/browse/COCOON-438?page=all ] Helma van der Linden closed COCOON-438: --- Resolution: Fixed [PATCH] Add a new logicsheet xsp-session-fw --- Key: COCOON-438 URL: http://issues.apache.org/jira/browse/COCOON-438 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.1.8-dev (Current SVN) Environment: Operating System: All Platform: All Reporter: Antonio Gallardo Assignee: Antonio Gallardo Attachments: new_patch_13070.zip, new_patch_13070.zip, session-fw-patch.zip, xsp-patch.zip This new tag for xsp-session, features the same as session:getxml. It is intended to be used by XSP developers to get SessionContext data. I hope it will find its place into Cocoon 2.1 :) -- 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] Reopened: (COCOON-445) [PATCH] build dist-bin broken in HEAD
[ http://issues.apache.org/jira/browse/COCOON-445?page=all ]
Helma van der Linden reopened COCOON-445:
-
reopened just to set the resolution to fixed
[PATCH] build dist-bin broken in HEAD
-
Key: COCOON-445
URL: http://issues.apache.org/jira/browse/COCOON-445
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.0.5-dev (Current CVS)
Environment: Operating System: All
Platform: All
Reporter: Alfred Nathaniel
Assignee: Cocoon Developers Team
Three different problems:
1.) copy tofile/todir mix-up
2.) INSTALL file name changed
3.) *-block.jar not including in cocoon.war
Here's the diff 1.269. Sorry, can't use cvs diff due to corporate firewall.
*** build.xml.orig Fri Sep 27 18:23:38 2002
--- build.xml Wed Oct 2 14:03:07 2002
***
*** 1796,1802
include name=*.properties/
/fileset
/copy
! copy file=INSTALL.src tofile=${dist.src}/INSTALL filtering=on/
chmod perm=+x file=${dist.src}/run.sh/
chmod perm=+x file=${dist.src}/build.sh/
--- 1796,1802
include name=*.properties/
/fileset
/copy
! copy file=INSTALL-SRC.txt tofile=${dist.src}/INSTALL
filtering=on/
chmod perm=+x file=${dist.src}/run.sh/
chmod perm=+x file=${dist.src}/build.sh/
***
*** 1862,1872
exclude name=servlet*.jar/
/fileset
/copy
copy file=${build.dir}/${name}.jar
tofile=${dist.bin}/webapp/WEB-INF/lib/${name}-${version}.jar/
copy file=${build.dir}/${name}-samples.jar
! tofile=${dist.bin}/webapp/WEB-INF/lib//
copy todir=${dist.bin}/docs
fileset dir=${build.docs}/
--- 1862,1878
exclude name=servlet*.jar/
/fileset
/copy
+ copy todir=${dist.bin}/webapp/WEB-INF/lib
+ fileset dir=${build.dir}
+ include name=*-block.jar/
+ /fileset
+ mapper type=glob from=*-block.jar to=cocoon-*-block.jar/
+ /copy
copy file=${build.dir}/${name}.jar
tofile=${dist.bin}/webapp/WEB-INF/lib/${name}-${version}.jar/
copy file=${build.dir}/${name}-samples.jar
! todir=${dist.bin}/webapp/WEB-INF/lib//
copy todir=${dist.bin}/docs
fileset dir=${build.docs}/
***
*** 1890,1896
include name=KEYS/
/fileset
/copy
! copy file=INSTALL.bin tofile=${dist.bin}/INSTALL filtering=on/
!-- Build the war file --
jar jarfile=${dist.bin}/${name}.war
--- 1896,1902
include name=KEYS/
/fileset
/copy
! copy file=INSTALL-BIN.txt tofile=${dist.bin}/INSTALL
filtering=on/
!-- Build the war file --
jar jarfile=${dist.bin}/${name}.war
--
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-445) [PATCH] build dist-bin broken in HEAD
[ http://issues.apache.org/jira/browse/COCOON-445?page=all ]
Helma van der Linden closed COCOON-445:
---
Resolution: Fixed
[PATCH] build dist-bin broken in HEAD
-
Key: COCOON-445
URL: http://issues.apache.org/jira/browse/COCOON-445
Project: Cocoon
Type: Bug
Components: * Cocoon Core
Versions: 2.0.5-dev (Current CVS)
Environment: Operating System: All
Platform: All
Reporter: Alfred Nathaniel
Assignee: Cocoon Developers Team
Three different problems:
1.) copy tofile/todir mix-up
2.) INSTALL file name changed
3.) *-block.jar not including in cocoon.war
Here's the diff 1.269. Sorry, can't use cvs diff due to corporate firewall.
*** build.xml.orig Fri Sep 27 18:23:38 2002
--- build.xml Wed Oct 2 14:03:07 2002
***
*** 1796,1802
include name=*.properties/
/fileset
/copy
! copy file=INSTALL.src tofile=${dist.src}/INSTALL filtering=on/
chmod perm=+x file=${dist.src}/run.sh/
chmod perm=+x file=${dist.src}/build.sh/
--- 1796,1802
include name=*.properties/
/fileset
/copy
! copy file=INSTALL-SRC.txt tofile=${dist.src}/INSTALL
filtering=on/
chmod perm=+x file=${dist.src}/run.sh/
chmod perm=+x file=${dist.src}/build.sh/
***
*** 1862,1872
exclude name=servlet*.jar/
/fileset
/copy
copy file=${build.dir}/${name}.jar
tofile=${dist.bin}/webapp/WEB-INF/lib/${name}-${version}.jar/
copy file=${build.dir}/${name}-samples.jar
! tofile=${dist.bin}/webapp/WEB-INF/lib//
copy todir=${dist.bin}/docs
fileset dir=${build.docs}/
--- 1862,1878
exclude name=servlet*.jar/
/fileset
/copy
+ copy todir=${dist.bin}/webapp/WEB-INF/lib
+ fileset dir=${build.dir}
+ include name=*-block.jar/
+ /fileset
+ mapper type=glob from=*-block.jar to=cocoon-*-block.jar/
+ /copy
copy file=${build.dir}/${name}.jar
tofile=${dist.bin}/webapp/WEB-INF/lib/${name}-${version}.jar/
copy file=${build.dir}/${name}-samples.jar
! todir=${dist.bin}/webapp/WEB-INF/lib//
copy todir=${dist.bin}/docs
fileset dir=${build.docs}/
***
*** 1890,1896
include name=KEYS/
/fileset
/copy
! copy file=INSTALL.bin tofile=${dist.bin}/INSTALL filtering=on/
!-- Build the war file --
jar jarfile=${dist.bin}/${name}.war
--- 1896,1902
include name=KEYS/
/fileset
/copy
! copy file=INSTALL-BIN.txt tofile=${dist.bin}/INSTALL
filtering=on/
!-- Build the war file --
jar jarfile=${dist.bin}/${name}.war
--
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
