[magnolia-dev] [JIRA] (BLOSSOM-217) Context initialization depends on context itself (?), IllegalStateException
Title: Message Title TLN created an issue Magnolia Blossom Module / BLOSSOM-217 Context initialization depends on context itself (?), IllegalStateException Issue Type: Bug Affects Versions: 3.0.7 Assignee: Tobias Mattsson Created: 10/Jul/15 10:05 PM Priority: Neutral Reporter: TLN Hi, I have a weird problem. It seems to be a bug, but I'm not 100% sure. I need some help with figuring it out though. java.lang.IllegalStateException: DialogCreationContext not set, dialog cannot be created without it [blossom-area-dialog:project.spring.web.blossom.controllers.templates.HomePageTemplate$StageArea] at info.magnolia.module.blossom.dialog.BlossomDialogDefinitionProvider.getDialogDefinition(BlossomDialogDefinitionProvider.java:67) at info.magnolia.ui.dialog.registry.DialogDefinitionRegistry.register(DialogDefinitionRegistry.java:96) at info.magnolia.module.blossom.template.TemplateExporter.registerAreaDialog(TemplateExporter.java:293) at info.magnolia.module.blossom.template.TemplateExporter.registerAreaDialogs(TemplateExporter.java:270) at info.magnolia.module.blossom.template.TemplateExporter.exportTemplates(TemplateExporter.java:202) at info.magnolia.module.blossom.template.TemplateExporter.onApplicationEvent(TemplateExporter.java:173) at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:151) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:128) at org.springframework.con
[magnolia-dev] [JIRA] (BLOSSOM-196) Duplicate request parameters after rewrite
TLN
updated BLOSSOM-196
Duplicate request parameters after rewrite
Change By:
TLN
(26/Nov/14 6:09 PM)
Description:
Hello there,I'm not sure this bug is caused by Blossom, but some investigation with the Java debugger indicated that this is the best first guess. If I'm wrong, then sorry, please forward it.In order to reproduce, please add this class to any Blossom project:{code}@Controller@Template(id=DummyTemplate.TEMPLATE_ID, title="Dummy Page")@RequestMapping(value="/dummypage")public class DummyTemplate{ public static final String TEMPLATE_ID="rr:pages/dummypage"; @RequestMapping(method=RequestMethod.GET) public @ResponseBody String handleRequest(HttpServletRequest request, @RequestParam(value="dummyparam") String dummyParam) { return "dummy param value: '"+dummyParam+"'"; }}{code}Now create a website called /dummy.html having this template and open/dummy.html?dummyparam=xyzin your browser.It prints this:dummy param value: 'xyz'This is correct.Now, please create rewrite rule like this:class: info.magnolia.cms.beans.config.RegexpVirtualURIMappingfromURI: /dummy2((\?.*)?)$(Please mind the backslash, Jira is not displaying it correctly unless in source view. I don't know how to escape it correctly)toURI: forward:/dummy.html$1Then open/dummy2?dummyparam=xyzin your browser.It should also print:dummy param value: 'xyz'However it prints this:dummy param value: 'xyz,xyz'Which is the bug.Thanks for looking into it. :)
PS: Platform is Tomcat 8 here. If this changes anything.
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-196) Duplicate request parameters after rewrite
TLN
created BLOSSOM-196
Duplicate request parameters after rewrite
Issue Type:
Bug
Affects Versions:
2.0.5
Assignee:
Tobias Mattsson
Created:
26/Nov/14 5:59 PM
Description:
Hello there,
I'm not sure this bug is caused by Blossom, but some investigation with the Java debugger indicated that this is the best first guess. If I'm wrong, then sorry, please forward it.
In order to reproduce, please add this class to any Blossom project:
@Controller
@Template(id=DummyTemplate.TEMPLATE_ID, title="Dummy Page")
@RequestMapping(value="/dummypage")
public class DummyTemplate
{
public static final String TEMPLATE_ID="rr:pages/dummypage";
@RequestMapping(method=RequestMethod.GET)
public @ResponseBody String handleRequest(HttpServletRequest request, @RequestParam(value="dummyparam") String dummyParam)
{
return "dummy param value: '"+dummyParam+"'";
}
}
Now create a website called /dummy.html having this template and open
/dummy.html?dummyparam=xyz
in your browser.
It prints this:
dummy param value: 'xyz'
This is correct.
Now, please create rewrite rule like this:
class: info.magnolia.cms.beans.config.RegexpVirtualURIMapping
fromURI: /dummy2((?.*)?)$
toURI: forward:/dummy.html$1
Then open
/dummy2?dummyparam=xyz
in your browser.
It should also print:
dummy param value: 'xyz'
However it prints this:
dummy param value: 'xyz,xyz'
Which is the bug.
Thanks for looking into it.
Project:
Magnolia Blossom Module
Priority:
Neutral
Reporter:
TLN
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-196) Duplicate request parameters after rewrite
TLN
updated BLOSSOM-196
Duplicate request parameters after rewrite
Change By:
TLN
(26/Nov/14 6:03 PM)
Description:
Hello there,I'm not sure this bug is caused by Blossom, but some investigation with the Java debugger indicated that this is the best first guess. If I'm wrong, then sorry, please forward it.In order to reproduce, please add this class to any Blossom project:{code}@Controller@Template(id=DummyTemplate.TEMPLATE_ID, title="Dummy Page")@RequestMapping(value="/dummypage")public class DummyTemplate{ public static final String TEMPLATE_ID="rr:pages/dummypage"; @RequestMapping(method=RequestMethod.GET) public @ResponseBody String handleRequest(HttpServletRequest request, @RequestParam(value="dummyparam") String dummyParam) { return "dummy param value: '"+dummyParam+"'"; }}{code}Now create a website called /dummy.html having this template and open/dummy.html?dummyparam=xyzin your browser.It prints this:dummy param value: 'xyz'This is correct.Now, please create rewrite rule like this:class: info.magnolia.cms.beans.config.RegexpVirtualURIMappingfromURI: /dummy2((\
\
?.*)?)$
(Please mind the backslash, Jira is not displaying it correctly unless in source view. I don't know how to escape it correctly)
toURI: forward:/dummy.html$1Then open/dummy2?dummyparam=xyzin your browser.It should also print:dummy param value: 'xyz'However it prints this:dummy param value: 'xyz,xyz'Which is the bug.Thanks for looking into it. :)
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-196) Duplicate request parameters after rewrite
TLN
updated BLOSSOM-196
Duplicate request parameters after rewrite
Change By:
TLN
(26/Nov/14 6:02 PM)
Description:
Hello there,I'm not sure this bug is caused by Blossom, but some investigation with the Java debugger indicated that this is the best first guess. If I'm wrong, then sorry, please forward it.In order to reproduce, please add this class to any Blossom project:{code}@Controller@Template(id=DummyTemplate.TEMPLATE_ID, title="Dummy Page")@RequestMapping(value="/dummypage")public class DummyTemplate{ public static final String TEMPLATE_ID="rr:pages/dummypage"; @RequestMapping(method=RequestMethod.GET) public @ResponseBody String handleRequest(HttpServletRequest request, @RequestParam(value="dummyparam") String dummyParam) { return "dummy param value: '"+dummyParam+"'"; }}{code}Now create a website called /dummy.html having this template and open/dummy.html?dummyparam=xyzin your browser.It prints this:dummy param value: 'xyz'This is correct.Now, please create rewrite rule like this:class: info.magnolia.cms.beans.config.RegexpVirtualURIMappingfromURI: /dummy2((\
\
?.*)?)$toURI: forward:/dummy.html$1Then open/dummy2?dummyparam=xyzin your browser.It should also print:dummy param value: 'xyz'However it prints this:dummy param value: 'xyz,xyz'Which is the bug.Thanks for looking into it. :)
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-177) Accessibility of container component models intended?
TLN
created BLOSSOM-177
Accessibility of container component models intended?
Issue Type:
Task
Assignee:
Tobias Mattsson
Created:
02/Jun/14 7:19 PM
Description:
Hi Tobias,
this request is neither clearly a bug nor clearly a task nor clearly a question, I just don't know what it is (that's kind of the question itself). Since I have a login to this Jira but not for the forum, please accept it here.
I have noticed if you put components on a page or you nest components in each other, the JSP rendering one inner component can access the model(s) of the outer component(s) and the container page, simply by writing $
{outercomponentmodelattribute}
as if this were a "native" model attribute to the component itself. As I found this quite surprising at first, I investigated further (long ago) and discovered something like that it results from the fact that the model is made accessible to the JSP by means of request attributes, and when reading request attributes nested requests traverse up the chain until they find a match. Something like this, I don't remember the details exactly. I remember there was some copying functionality involved at some point, and I believe to remember that it was Blossom code, not Spring code.
As such I believe this behavior wasn't intended by you (and might even be still unknown to you), it's more a side effect of how other things in your framework are working.
Now, the reason why I'm writing: I'm making use of this behavior at a couple of places in my code in different projects already, very gratefully by the way, because if this side effect wasn't there, I don't think there would be anything even nearly as elegant to make components context-sensitive.
On the other hand, ... relying on a side effect is a little dangerous. That's the reason why I'm asking: Could you make the fact that request.getAttribute("[anything]") returns a model attribute of an outer component or page (if it exists under that name) documented behaviour so that we can safely rely on it? Otherwise I'd always be scared that several projects could suddenly be broken if they switch to a later version of Blossom, knowing that this would not be trivial to fix.
If it already IS documented and I've missed that, then please forgive me.
Thanks a lot.
Torsten
Project:
Magnolia Blossom Module
Priority:
Neutral
Reporter:
TLN
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-154) Useful Component Inheritance Use Case
TLN updated BLOSSOM-154 Useful Component Inheritance Use Case Change By: TLN (02/Jun/14 4:31 PM) Description: A very typical use case on many websites that I know is this:You have a header area, and any header component that you place there should be inherited by all child pages because typically pages use the same header. Yet, there are a few child pages that do not want to inherit the header, they want to have their own one. There are several reasons for that, sometimes you need additional disclaimers linked, specific language selector links, highlight certain menu items, etc.I tried a lot to find an elegant out-of-the-box way to implement this, these are the results (only relevant attributes are given below, and when I say "header" it's just an example of course):1. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.ALL)--> You can only add another header on a sub-page but not ignore the inherited one. So you end up with several headers on the page.2. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.FILTERED)--> You can ignore the inherited one, that's very close, but then that non-inheritance is general and effects all children, not just one single page that wants to specifically override the header.3. @Area(type=AreaType. LIST, maxComponents="1") @Inherits(components=ComponentInheritanceMode.ALL)--> Like 1. but when I add the second header on the sub-page it isn't shown (only the inherited headers is shown), so I can't even correct my "mistake" and delete the additional header. I have to use the JCR browser to set it right.4. @Area(type=AreaType.LIST, maxComponents="1") @Inherits(components=ComponentInheritanceMode.FILTERED)--> Same problems as described for 2. and 3.5. @Area(type=AreaType. SINGLE) @Inherits(components=ComponentInheritanceMode.ALL)--> Exception on the sub-page with the intended header override: Can't render single area [node ...]: expected one component node but found more.And so on (I'm not listing all possible combinations; I'm sure you have an idea).What I think is that case 5. should work as needed for that header use case; it's the natural assumption that when you define SINGLE and you place a header on any child page, that implicitely nothing is inherited and it only uses its own newly defined header.Thanks. 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 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:
[magnolia-dev] [JIRA] (BLOSSOM-154) Useful Component Inheritance Use Case
TLN updated BLOSSOM-154 Useful Component Inheritance Use Case Change By: TLN (02/Jun/14 4:31 PM) Description: A very typical use case on many websites that I know is this:You have a header area, and any header component that you place there should be inherited by all child pages because typically pages use the same header. Yet, there are a few child pages that do not want to inherit the header, they want to have their own one. There are several reasons for that, sometimes you need additional disclaimers linked, specific language selector links, highlight certain menu items, etc.I tried a lot to find an elegant out-of-the-box way to implement this, these are the results (only relevant attributes are given below, and when I say "header" it's just an example of course):1. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.ALL)--> You can only add another header on a sub-page but not ignore the inherited one. So you end up with several headers on the page.2. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.FILTERED)--> You can ignore the inherited one, that's very close, but then that non-inheritance is general and effects all children, not just one single page that wants to specifically override the header.3. @Area(type=AreaType.SINGLE) @Inherits(components=ComponentInheritanceMode.ALL)--> Exception on the sub-page with the intended header override: Can't render single area [node ...]: expected one component node but found more.And so on (I'm not listing all possible combinations; I'm sure you have an idea).What I think is that case 5 3 . should work as needed for that header use case; it's the natural assumption that when you define SINGLE and you place a header on any child page, that implicitely nothing is inherited and it only uses its own newly defined header.Thanks. 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 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:
[magnolia-dev] [JIRA] (BLOSSOM-174) Areas don't seem to respect exclusion rules from component-scan
TLN created BLOSSOM-174 Areas don't seem to respect exclusion rules from component-scan Issue Type: Bug Assignee: Tobias Mattsson Created: 05/May/14 12:30 AM Description: Hi Tobias, in my blossom-servlet.xml I use the following code inspired by the Maven archetype: package="xzy" use-default-filters="false"> "annotation" _expression_="info.magnolia.module.blossom.annotation.Template"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.Area"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.DialogFactory"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.VirtualURIMapper"/> This works well as such. Now, one of the next steps in our project was using different spring profiles (see http://spring.io/blog/2011/02/11/spring-framework-3-1-m1-released/) because our project has different deployment types which partially require different templates (i.e. Spring Controllers) and we didn't want to confuse the editors with templates being shown as available in the backend although they're not applicable in the current mode. Thus I created different profiles like this: "abc"> package="xzy" use-default-filters="false"> "annotation" _expression_="info.magnolia.module.blossom.annotation.Template"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.Area"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.DialogFactory"/> "annotation" _expression_="info.magnolia.module.blossom.annotation.VirtualURIMapper"/> "annotation" _expression_="my.Annotation"/> This, too, is finally working after a lot of research and trial and error. I'm very happy about that. At least it is working for Controllers. That's good news. However, it is not working for Areas. Although I proved with the debugger in org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider (line 329, in method isCandidateComponent()) that the area in question is reported as excluded by Spring, the excluded area is finally created in the rendering phase. You will probably argue it's not a problem, I'm not forced to use any area in my JSP file if I don't like it. However the idea is to have several @Area classes in one controller which have the same are name (e.g. several areas with the signature @Area(value="sidebar", title="Sidebar") ) and to make them mutually exclusive by the marker annotations as just described. If Blossom doesn't respect the exclusion rules, like it seems, this approach won't work. The whole subject is a little tricky, I can't guarantee that the problem is with Blossom, but because everything else is working as described above, it's hard to find another explanation at the moment. Thanks a lot for looking into it on occasion. Best Regards, Torsten Project: Magnolia Blossom Module Priority: Neutral Reporter: TLN 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 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:
[magnolia-dev] [JIRA] (BLOSSOM-154) Useful Component Inheritance Use Case
TLN created BLOSSOM-154 Useful Component Inheritance Use Case Issue Type: Improvement Assignee: Tobias Mattsson Created: 03/Dec/13 1:23 PM Description: A very typical use case on many websites that I know is this: You have a header area, and any header component that you place there should be inherited by all child pages because typically pages use the same header. Yet, there are a few child pages that do not want to inherit the header, they want to have their own one. There are several reasons for that, sometimes you need additional disclaimers linked, specific language selector links, highlight certain menu items, etc. I tried a lot to find an elegant out-of-the-box way to implement this, these are the results (only relevant attributes are given below, and when I say "header" it's just an example of course): 1. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.ALL) --> You can only add another header on a sub-page but not ignore the inherited one. So you end up with several headers on the page. 2. @Area(type=AreaType.LIST) @Inherits(components=ComponentInheritanceMode.FILTERED) --> You can ignore the inherited one, that's very close, but then that non-inheritance general and effects all children, not just one single page that wants to specifically override the header. 3. @Area(type=AreaType.LIST, maxComponents="1") @Inherits(components=ComponentInheritanceMode.ALL) --> Like 1. but when I add the second header on the sub-page it isn't shown (only the inherited headers is shown), so I can't even correct my "mistake" and delete the additional header. I have to use the JCR browser to set it right. 4. @Area(type=AreaType.LIST, maxComponents="1") @Inherits(components=ComponentInheritanceMode.FILTERED) --> Same problems as described for 2. and 3. 5. @Area(type=AreaType.SINGLE) @Inherits(components=ComponentInheritanceMode.ALL) --> Exception on the sub-page with the intended header override: Can't render single area [node ...]: expected one component node but found more. And so on (I'm not listing all possible combinations; I'm sure you have an idea). What I think is that case 5. should work as needed for that header use case; it's the natural assumption that when you define SINGLE and you place a header on any child page, that implicitely nothing is inherited and it only uses its own newly defined header. Thanks. Project: Magnolia Blossom Module Priority: Neutral Reporter: TLN 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 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:
[magnolia-dev] [JIRA] (BLOSSOM-145) Support for areas with class inheritance
TLN
created BLOSSOM-145
Support for areas with class inheritance
Issue Type:
Improvement
Assignee:
Tobias Mattsson
Created:
16/Oct/13 2:24 PM
Description:
The issue is best explained by an example:
@Controller
public class FooterCapablePage
{
@Area(value="footer", title="Footer Area", maxComponents="1")
@AvailableComponentClasses({
PageFooterComponent.class,
})
@Controller
public static class PageFooterArea
{
@RequestMapping("/footerCapablePage/footerArea")
public String render()
{
return "areas/componentIterator";
}
}
}
@Template(id="vwm:articlePage", title="Article Page")
@Controller
public class ArticlePageTemplate extends FooterCapablePage
{
@RequestMapping("/articlepage")
public String handleRequest()
{
return "/pages/article";
}
}
It would be great and avoid a lot of redundant code if /pages/article.jsp could use in this scenario, but currently that doesn't work (the area isn't rendered, no components can be put in it). Only if the area is defined in ArticlePageTemplate itself, Blossom will accept it.
Spring annotations like @ModelAttribute or some other Blossom annotations like @TabFactory support inheritance.
Thank you.
Project:
Magnolia Blossom Module
Priority:
Neutral
Reporter:
TLN
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
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:
[magnolia-dev] [JIRA] (BLOSSOM-130) Nesting the same JSP + Performance impact
TLN
updated BLOSSOM-130
Nesting the same JSP + Performance impact
Change By:
TLN
(13/Sep/13 1:02 PM)
Description:
The problem I'm going to describe is a little complex and seems to have enough potential to cause you some headache just to understand what's going on, not to mention any attempts to fix it safely.It's unlikely you'll understand it in just a few minutes, but please try to dig in it, it seems to point to a notable performance implication at the very least, and a functional bug in any case.The original reason why I investigated on this problem was that I usually want to use the same JSP for most of my areas (a 3-liner that simply iterates over all components in the area and displays them one by one).However each time I try this kind of thing, embedding the file named {{componentIterator.jsp}} twice in the hierarchy of components and areas, I get an exception saying something like this:{code}javax.servlet.ServletException: File "/startPageSlider" not found.{code}This is the functional bug I mentioned above.I spent hours trying to figure out how Blossom is even getting the idea to look for a file named "/startPageSlider" which is the *request mapping* of the component *containing* the area and shouldn't have much to do with the path of the *JSP* *rendering* the area. And even if it did have anything to do with it, ... why is Blossom trying to look for an actual file there, and why only under these conditions (two nested areas using the same JSP)?While investigating on this I soon came across the class {code}info.magnolia.module.blossom.support.SpecialAttributeRequestWrapper{code} which seems to be the culprit in at least two ways.The main problem that became apparent and which I'm going to mention first is that the two methods {{getAttribute()}} and {{shouldMasquerade()}} create huge recursion stacks in real life because they call each other back and forth all the time. Granted, {{shouldMasquerade()}} calls the super version, so it seems harmless at first glance, but since that one in turn calls the {{getAttribute()}} of the parent request object, which is usually another instance of {{SpecialAttributeRequestWrapper}}, the result is a huge "explosion" of requests from {{getAttribute()}} to {{shouldMasquerade()}} and from {{shouldMasquerade()}} back to {{getAttribute()}} and so on. This effect is even aggravated by two factors:1. Even when {{shouldMasquarade()}} has already determined the result of a {{super.getAttribute(xxx)}}, the calling {{getAttribute(xxx)}} calls {{super.getAttribute(xxx)}} again, causing another cycle through a dozen to a couple of hundreds of calls of {{getAttribute()}} and {{shouldMasquarade()}} back and forth.2. {{shouldMasquarade()}} doesn't just check the attribute at hand for modifications but ALL attributes, causing up to 15 calls to {{getAttribute()}} from each single call to {{shouldMasquarade()}}. (I'm not sure this in itself is intended because {{shouldMasquarade()}} isn't using its method argument, which it probably should do.)To verify what I'm saying, please do the following:1. Create some simple hierarchy of areas and components, something like this:page (p.jsp) -> area (a1.jsp) -> component (c1.jsp) -> area (a2.jsp) -> component (c2.jsp) -> area (a3.jsp) -> component (c3.jsp)and create a page where this structure is populated with actual instances.(Two or three component levels are sufficient to demonstrate the problem, but it'll really explode if you have more than three levels since the problem has exponential complexity.)2. Now just create some simple log statements in the source code to log how many times you're iterating over the {{specialNames}} in class SpecialAttributeRequestWrapper within just one page request, i.e. insert a log statement in {{getAttribute()}} and one in {{shouldMasquarade()}}.3. Then run the page and watch the log.4. You will be surprised by the hundreds of iterations/recursive calls there, given this simple page configuration. And you might note you're just computing the same values again and again, visiting the same recursion branches again and again.The performance implications should be obvious, it's a huge waste of CPU like this. And it makes it really hard to understand, to debug, and to maint
[magnolia-dev] [JIRA] (BLOSSOM-130) Nesting the same JSP + Performance impact
TLN created BLOSSOM-130 Nesting the same JSP + Performance impact Issue Type: Bug Affects Versions: 2.0.1, 3.0 Assignee: Tobias Mattsson Created: 13/Sep/13 12:50 PM Description: The problem I'm going to describe is a little complex and seems to have enough potential to cause you some headache just to understand what's going on, not to mention any attempts to fix it safely. It's unlikely you'll understand it in just a few minutes, but please try to dig in it, it seems to point to a notable performance implication at the very least, and a functional bug in any case. The original reason why I investigated on this problem was that I usually want to use the same JSP for most of my areas (a 3-liner that simply iterates over all components in the area and displays them one by one). However each time I try this kind of thing, embedding the file named componentIterator.jsp twice in the hierarchy of components and areas, I get an exception saying something like this: javax.servlet.ServletException: File "/startPageSlider" not found. This is the functional bug I mentioned above. I spent hours trying to figure out how Blossom is even getting the idea to look for a file named "/startPageSlider" which is the request mapping of the component containing the area and shouldn't have much to do with the path of the JSP rendering the area. And even if it did have anything to do with it, ... why is Blossom trying to look for an actual file there, and why only under these conditions (two nested areas using the same JSP)? While investigating on this I soon came across the class info.magnolia.module.blossom.support.SpecialAttributeRequestWrapper which seems to be the culprit in at least two ways. The main problem that became apparent and which I'm going to mention first is that the two methods getAttribute() and shouldMasquerade() create huge recursion stacks in real life because they call each other back and forth all the time. Granted, shouldMasquerade() calls the super version, so it seems harmless at first glance, but since that one in turn calls the getAttribute() of the parent request object, which is usually another instance of SpecialAttributeRequestWrapper, the result is a huge "explosion" of requests from getAttribute() to shouldMasquerade() and from shouldMasquerade() back to getAttribute() and so on. This effect is even aggravated by two factors: 1. Even when shouldMasquarade() has already determined the result of a super.getAttribute(xxx), the calling getAttribute(xxx) calls super.getAttribute(xxx) again, causing another cycle through a dozen to a couple of hundreds of calls of getAttribute() and shouldMasquarade() back and forth. 2. shouldMasquarade() doesn't just check the attribute at hand for modifications but ALL attributes, causing up to 15 calls to getAttribute() from each single call to shouldMasquarade(). (I'm not sure this in itself is intended because shouldMasquarade() isn't using its method argument, which it probably should do.) To verify what I'm saying, please do the following: 1. Create some simple hierarchy of areas and components, something like this: page (p.jsp) -> area (a1.jsp) -> component (c1.jsp) -> area (a2.jsp) -> component (c2.jsp) -> area (a3.jsp) -> component (c3.jsp) and create a page where this structure is populated with actual instances. (Two or three component levels are sufficient to demonstrate the problem, but it'll really explode if you have more than three levels since the problem has exponential complexity.) 2. Now just create some simple log statements in the source code to log how many times you're iterating over the specialNames in class SpecialAttributeRequestWrapper within just one page request, i.e. insert a log statement in getAttribute() and one in shouldMasquarade(). 3. Then run the page and watch the log. 4. You will be surprised by the hundreds of iterations/recursive calls there, given this simple page configuration. And you might note you're just computing the same values again and again, visiting the same recursion branches again and again. T
