[magnolia-dev] [JIRA] (BLOSSOM-189) BlossomDispatcherServlet should implement all DispatcherServlet constructors
Andreas Antener created BLOSSOM-189 BlossomDispatcherServlet should implement all DispatcherServlet constructors Issue Type: Improvement Affects Versions: 3.0.3 Assignee: Tobias Mattsson Created: 25/Aug/14 3:04 PM Description: Hi Tobias Since Blossom 3 depends on Spring 3 now, it would be great if you could add both constructors from DispatcherServlet to BlossomDispatcherServlet. Without that we cannot instantiate the servlet with a programmatically created application context (requires public DispatcherServlet(WebApplicationContext webApplicationContext)) We're currently using a workaround I'd like to get rid of Kind regards, Andreas Project: Magnolia Blossom Module Priority: Neutral Reporter: Andreas Antener This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MAGNOLIA-4580) Areas ignore their i18nBasename
Andreas Antener updated MAGNOLIA-4580 Areas ignore their i18nBasename Change By: Andreas Antener (23/May/13 2:48 PM) Patch included: Yes Testcase included: Yes This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MAGNOLIA-5058) HostBasedVirtualURIMapping does not work with forwards/redirects that have URL parameters
Andreas Antener created MAGNOLIA-5058 HostBasedVirtualURIMapping does not work with forwards/redirects that have URL parameters Issue Type: Bug Affects Versions: 4.5.8 Assignee: Unassigned Attachments: HostBasedVirtualURIMapping.patch.diff, HostBasedVirtualURIMappingTest.java Components: core Created: 23/May/13 2:47 PM Description: HostBasedVirtualURIMapping does not accept target URLs with parameters. It has to do with the way it splits each host entry by '='. Patch and test case attached. Project: Magnolia Priority: Neutral Reporter: Andreas Antener Security Level: Public This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] (MAGNOLIA-4580) Areas ignore their i18nBasename
Andreas Antener updated MAGNOLIA-4580 Areas ignore their i18nBasename To clarify this issue: The problem is that the title property of the area will not be looked up in the message bundle specified by the i18nBasename from the area itself. Instead, it will be resolved with the message bundle specified by its parent (the parent area or template definition). I propose a change in info.magnolia.templating.elements.AreaElement. See attached patch (includes a test case). The patched version will look for an i18nBasename on the area definition first, and it will fall back to the parent definition if there is none declared on the area. I admit that this is a minor issue, but if the labels don't get resolved it always looks like there's something broken on the front end. Also I believe that the new behaviour would be more consistent with how i18nBasename and label/description properties work on components. Unfortunately I'm not quite sure how big the risk of breaking existing configurations would be. Regards, Andy Change By: Andreas Antener (08/Feb/13 6:37 PM) Attachment: patch.diff This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html Alternatively,useourforums:http://forum.magnolia-cms.com/ Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MGNLWORKFLOW-18) Empty nodes of finished workflow still exist (Expressions workspace)
[ http://jira.magnolia-cms.com/browse/MGNLWORKFLOW-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Antener updated MGNLWORKFLOW-18: Attachment: JCRExpressionStoreCleanupTest.java patch.diff Attached test case and patch. There is a problem with the use of org.apache.jackrabbit.commons.iterator.FilteringNodeIterator in info.magnolia.module.workflow.jcr.JCRExpressionStore#deleteAndRemoveEmptyParents The check on size()==0 cannot work because the implementation of this filtering node iterator always returns -1. It is explained in javax.jcr.RangeIterator#getSize Cheers Andy Empty nodes of finished workflow still exist (Expressions workspace) Key: MGNLWORKFLOW-18 URL: http://jira.magnolia-cms.com/browse/MGNLWORKFLOW-18 Project: Magnolia Workflow Module Issue Type: Bug Environment: Magnolia EE 4.5.6, Tomcat 7, Java 6, OS X Reporter: Andreas Antener Priority: Minor Fix For: 1.0 Alpha2 s011 Attachments: expressions.txt, JCRExpressionStoreCleanupTest.java, libs.txt, magnolia-debug.log, patch.diff The nodes in the Expressions workspace won't get deleted after a finished workflow. Steps to reproduce: - Start Magnolia (public and author) with workflow module, no repositories yet - Login with superuser - Create a page - Activate that page - Go to inbox and proceed with the activation - Check the Expressions workspace under /owfe/activation There I have 2 empty nodes now. See attachments for debug-log, libs and listing from JCR query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MGNLWORKFLOW-18) Empty nodes of finished workflow still exist (Expressions workspace)
Empty nodes of finished workflow still exist (Expressions workspace) Key: MGNLWORKFLOW-18 URL: http://jira.magnolia-cms.com/browse/MGNLWORKFLOW-18 Project: Magnolia Workflow Module Issue Type: Bug Environment: Magnolia EE 4.5.6, Tomcat 7, Java 6, OS X Reporter: Andreas Antener Assignee: Jozef Chocholacek Priority: Minor Attachments: expressions.txt, libs.txt, magnolia-debug.log The nodes in the Expressions workspace won't get deleted after a finished workflow. Steps to reproduce: - Start Magnolia (public and author) with workflow module, no repositories yet - Login with superuser - Create a page - Activate that page - Go to inbox and proceed with the activation - Check the Expressions workspace under /owfe/activation There I have 2 empty nodes now. See attachments for debug-log, libs and listing from JCR query. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-4576) Change comment on versions repeats itself after restoring deleted pages
Change comment on versions repeats itself after restoring deleted pages --- Key: MAGNOLIA-4576 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4576 Project: Magnolia Issue Type: Bug Security Level: Public Components: core Affects Versions: 4.5.4 Reporter: Andreas Antener Assignee: Philipp Bärfuss Priority: Minor Attachments: Screen Shot 2012-10-10 at 18.34.41.png We enabled versioning for the website repository without using the workflow module. Versioning is enabled on the 'activate' and 'deactivate' commands. When we delete a page and restore the deleted version, the comment in the version history repeats itself for all the following versions created by activations. See attached screenshot: 1. version created before deletion 2. version created before restoration 3. followup activation, copies comment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-4580) Areas ignore their i18nBasename
Areas ignore their i18nBasename --- Key: MAGNOLIA-4580 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4580 Project: Magnolia Issue Type: Bug Security Level: Public Components: templating Affects Versions: 4.5.4 Reporter: Andreas Antener Assignee: Philipp Bärfuss Priority: Minor Attachments: Screen Shot 2012-10-12 at 12.06.24.png If we add a new area to the prototype with custom i18nBasename, the title will not be loaded on STK pages. Instead it shows the label. See attached screenshot with area configuration. (the area will be enabled on certain pages, eg. stkArticle) The same problem occurs if I want to add an area from STK to a custom component. E.g.: - myTeaser -- templateScript: /module/components/myTeaser.ftl -- i18nBasename: com.module.messages -- title: myTeaser.title -- areas --- linkList i18nBasename: info.magnolia.module.templatingkit.messages (manually added) title: areas.components.linkList.title Now the title from the STK area will not show. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3225) Administratoren-Instanec magnoliaAuthor cannot be started
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=28630#action_28630 ] Andreas Antener commented on MAGNOLIA-3225: --- Hi Zdenek Thanks for your mail. Recreating the index did not help. Do you have any other idea? Should we delete lock files? Best regards Peter (on behalf of Andreas) Administratoren-Instanec magnoliaAuthor cannot be started - Key: MAGNOLIA-3225 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3225 Project: Magnolia Issue Type: Bug Components: admininterface Affects Versions: 4.2.1 Environment: Tomcat Windows Reporter: Andreas Antener Assignee: Zdenek Skodik Attachments: catalina.2010-06-10.zip Access to ../magnoliaAuthor/admin hangs (html code transfered but login screen ist not visible) no access to files in repository Please call Peter Mohn, +41 76 332 28 44 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3225) Administratoren-Instanec magnoliaAuthor cannot be started
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=28632#action_28632 ] Andreas Antener commented on MAGNOLIA-3225: --- Hi Zdenek I need to Andreas jira id (ada). It's used as our shared access. Regards Peter Administratoren-Instanec magnoliaAuthor cannot be started - Key: MAGNOLIA-3225 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3225 Project: Magnolia Issue Type: Bug Components: admininterface Affects Versions: 4.2.1 Environment: Tomcat Windows Reporter: Andreas Antener Assignee: Zdenek Skodik Attachments: catalina.2010-06-10.zip Access to ../magnoliaAuthor/admin hangs (html code transfered but login screen ist not visible) no access to files in repository Please call Peter Mohn, +41 76 332 28 44 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3225) Administratoren-Instanec magnoliaAuthor cannot be started
Administratoren-Instanec magnoliaAuthor cannot be started - Key: MAGNOLIA-3225 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3225 Project: Magnolia Issue Type: Bug Components: admininterface Affects Versions: 4.2.1 Environment: Tomcat Windows Reporter: Andreas Antener Assignee: Philipp Bärfuss Attachments: catalina.2010-06-10.zip Access to ../magnoliaAuthor/admin hangs (html code transfered but login screen ist not visible) no access to files in repository Please call Peter Mohn, +41 76 332 28 44 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2909) POST requests to Magnolia fail if Struts filter chain is used before the Magnolia chain
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=24740#action_24740 ] Andreas Antener commented on MAGNOLIA-2909: --- Thank you for the hint. I had a short look into the code. Basically what you are doing is delegating the action to struts for processing in a renderer, right? In the meanwhile I tried to do something similar with a filter in the Magnolia filter chain. My filter just delegates the request to the struts dispacher. It works with post-requests if the filter is positioned after multipartRequest. Also it was necessary to check on loops because struts calls Magnolia sites as result pages, which is why I'm not quite sure if this is the correct approach to solve it.. POST requests to Magnolia fail if Struts filter chain is used before the Magnolia chain --- Key: MAGNOLIA-2909 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2909 Project: Magnolia Issue Type: Bug Affects Versions: 4.1.1 Environment: struts 2.1.6, tomcat 6 Reporter: Andreas Antener Assignee: Boris Kraft Attachments: stacktrace.txt, web.xml First, what are we trying to do: We have already existing applications that are using Struts and we would like to integrate them in Magnolia. The idea is to use these existing applications as paragraphs, which can be placed anywhere on the site. JSP templates came in handy to include pages that are using struts tags. We added the struts filter-dispacher and mapped him BEFORE magnolia (see attachement). From now on, struts tags get executed and they work as expected. However, the thing that does not work anymore are POST requests that are directed to Magnolia itself (meaning every Magnolia dialog / input etc.). Magnolia terminates parsing those request with the following exception: java.io.IOException: Corrupt form data: premature ending com.oreilly.servlet.multipart.MultipartParser.init(MultipartParser.java:205) com.oreilly.servlet.MultipartRequest.init(MultipartRequest.java:222) info.magnolia.cms.filters.CosMultipartRequestFilter.parseParameters(CosMultipartRequestFilter (see attachement for full stacktrace) I read that this could be an MultipartParser-library related incompatibility with Struts: http://stackoverflow.com/questions/240163/corrupt-form-data-premature-ending-resolved Any suggestions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Commented: (MAGNOLIA-2894) Wrong content-encoding in HTTP header prevents not authorized pages from beeing displayed
[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=24588#action_24588 ] Andreas Antener commented on MAGNOLIA-2894: --- Ok, the voter for not caching if authenticated is a workaround, but caching for logged in user should be possible imho. You can still produce the error though. I tried to figure out the steps necessary: - setup magnoliaAuthor and magnoliaPublic instances (I used the enterprise version 4.1.1 with samples module and PUR module) - browse on the public instance and get the demo-project site cached - configure the anonymous role like the following: read acces for the whole website (/) but deny /demo-project/service, and url access for get post to /* - activate the anonymous role - now I still see the Service menu item on demo-project. When I go there (and on the sub-sites) I get the described error Wrong content-encoding in HTTP header prevents not authorized pages from beeing displayed --- Key: MAGNOLIA-2894 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2894 Project: Magnolia Issue Type: Bug Components: cache Affects Versions: 4.1.1 Environment: Tested browsers: Firefox 3, IE 7 Reporter: Andreas Antener Assignee: Boris Kraft Priority: Minor Attachments: encoding problem.jpg In some cases, where the currently logged-in user has no access to the requested site, the browser is not able to display the response (see attachement). If the cache is completely disabled everything works as expected so we suspect that caching the forbidden pages causes the problem. Also if ACLs get changed through the author instance, those cached pages don't get flushed (this is pretty confusing while testing security). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-2909) POST requests to Magnolia fail if Struts filter chain is used before the Magnolia chain
POST requests to Magnolia fail if Struts filter chain is used before the Magnolia chain --- Key: MAGNOLIA-2909 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2909 Project: Magnolia Issue Type: Bug Affects Versions: 4.1.1 Environment: struts 2.1.6, tomcat 6 Reporter: Andreas Antener Assignee: Boris Kraft Attachments: stacktrace.txt, web.xml First, what are we trying to do: We have already existing applications that are using Struts and we would like to integrate them in Magnolia. The idea is to use these existing applications as paragraphs, which can be placed anywhere on the site. JSP templates came in handy to include pages that are using struts tags. We added the struts filter-dispacher and mapped him BEFORE magnolia (see attachement). From now on, struts tags get executed and they work as expected. However, the thing that does not work anymore are POST requests that are directed to Magnolia itself (meaning every Magnolia dialog / input etc.). Magnolia terminates parsing those request with the following exception: java.io.IOException: Corrupt form data: premature ending com.oreilly.servlet.multipart.MultipartParser.init(MultipartParser.java:205) com.oreilly.servlet.MultipartRequest.init(MultipartRequest.java:222) info.magnolia.cms.filters.CosMultipartRequestFilter.parseParameters(CosMultipartRequestFilter (see attachement for full stacktrace) I read that this could be an MultipartParser-library related incompatibility with Struts: http://stackoverflow.com/questions/240163/corrupt-form-data-premature-ending-resolved Any suggestions? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-2894) Wrong content-encoding in HTTP header prevents not authorized pages from beeing displayed
Wrong content-encoding in HTTP header prevents not authorized pages from beeing displayed --- Key: MAGNOLIA-2894 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2894 Project: Magnolia Issue Type: Bug Components: cache Affects Versions: 4.1.1 Environment: Tested browsers: Firefox 3, IE 7 Reporter: Andreas Antener Assignee: Boris Kraft Priority: Minor Attachments: encoding problem.jpg In some cases, where the currently logged-in user has no access to the requested site, the browser is not able to display the response (see attachement). If the cache is completely disabled everything works as expected so we suspect that caching the forbidden pages causes the problem. Also if ACLs get changed through the author instance, those cached pages don't get flushed (this is pretty confusing while testing security). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
