ui:include of multiple p:column into two distinct composite components leads to Stackoverflow

UI Components for JSF
Post Reply
webel
Posts: 87
Joined: 18 Sep 2010, 09:29
Location: Sydney, Australia
Contact:

17 Nov 2017, 10:16

Java version: 1.8.0_102; Mojarra: 2.3.0; Primefaces: 6.1.RC2 (community edition);

I have not yet isolated this as a dedicated test case, and the XHTML/JSF code is far too complex to reproduce here (being the reason I used ui:include) but I can at least describe it so that if somebody else encounters the same strange problem they know where to look.

I have two composite components, let's call them A and B.

They both involve very large complex p:dataTable, but slightly different, yet share exactly many of the p:column. So for the sake of Don't Repeat Yourself (DRY) coding I used a ui:include of the multiple p:column into both of the 2 separate CCs, A and B.

This worked fine for a couple of days. I kept working on the mutually included section, introducing new p:column columns, then suddenly started getting StackOverflowError errors:

Code: Select all

java.lang.StackOverflowError
at com.sun.el.lang.EvaluationContext.getContext(EvaluationContext.java:91)
at com.sun.faces.el.ImplicitObjectELResolver.getValue(ImplicitObjectELResolver.java:110)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:180)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:208)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
at com.sun.el.parser.AstValue.getBase(AstValue.java:151)
at com.sun.el.parser.AstValue.getValue(AstValue.java:200)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:159)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:115)
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:2487)
at com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.get(CompositeComponentAttributesELResolver.java:405)
at javax.el.MapELResolver.getValue(MapELResolver.java:199)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:180)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:208)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:159)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:115)
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:2487)
at com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.get(CompositeComponentAttributesELResolver.java:405)
at javax.el.MapELResolver.getValue(MapELResolver.java:199)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:180)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:208)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
I scratched my head (but not enough to go bald) looking for what could be the cause, and convinced myself there was nothing that would cause recursion.

Then I thought to simply comment out the ui:include from both "client" CCs, A and B, and paste the complex multiple-column p:column code back into A, and it all worked fine. I then pasted it also into B, and it still worked fine.

It's reproducible. Something about using the ui:include across the multiple p:column is throwing it, and I could not yet find out what (the culprit included code looks innocent to me, but as said, way too complex to show here).

A crying shame, as the ui:include included code is very complex, and reproducing/editing/managing it it in two different CC contexts is labourious and horribly WET (Write Everything Twice, a.k.a. We Enjoy Typing).

Q1: Can anyone think of anything that could cause this ?

Q2: Is there anyway to encapsulate just the p:column aspect of multiple columns within a p:dataTable as a composite component ?

I would be surprised if anybody can answer Q1 without some tricky testing. It's a pathological gotcha.

I would be very suprised if there is a solution to Q2.

Will try to isolate it as a test case, but for now the questions stand as described.

Also, don't know whether it happens anyway with h:column (might be something about JSF vs p:dataTable or might not have anything to do with PrimeFaces at all).
Primefaces 6.1
JSF Mojarra 2.3.0
(Netbeans 8.2+Glassfish 4.1.1 OR Payara 4.1)
Mac OS X "Yosemite" 10.10.5 / Linux CentOS 6.7

Melloware
Posts: 3717
Joined: 22 Apr 2013, 15:48

19 Nov 2017, 21:23

This may be a dumb question and it doesn't address the core stack overflow bug you are reporting but can you find a way to make your CC more generic so 1 CC with all the passed in values supports both your use cases? Rather than having 2 CC with similar datatable guts?
PrimeFaces Developer | PrimeFaces Extensions Developer
GitHub Profile: https://github.com/melloware
PrimeFaces Elite 13.0.0 / PF Extensions 13.0.0
PrimeReact 9.6.1

Post Reply

Return to “PrimeFaces”

  • Information
  • Who is online

    Users browsing this forum: No registered users and 22 guests