from:"Andy Schwartz $JIRA$"

[jira] [Updated] (TRINIDAD-2515) Avoid caching skins from external SkinProviders and make LRU cache concurrent

2014-10-16 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2515:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed in r1632265.

 Avoid caching skins from external SkinProviders and make LRU cache concurrent
 -

 Key: TRINIDAD-2515
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2515
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
 Attachments: jira-2515.patch, test-skin-and-images.zip


 Problem statement:
 SkinProvider SPI allows creation of external skin repositories and plug it 
 into trinidad skin framework. Skin framework should allow such skins to be 
 managed (created, cached, destroyed) by the SkinProvider. Currently this is 
 not happening.
 Internal problem description:
 When user requests a Skin, skin framework creates a StyleProvider for it. 
 This StyleProvider is cached at application level and reused for subsequent 
 requests for the same Skin. Since the StyleProvider contains the Skin, it 
 effectively caches the Skin also.
 Solution:
 Don't cache StyleProvider associated with Skins served from external 
 SkinProviders. For achieveing this introduce isCacheable API on SkinImpl and 
 implement it in SkinExtension:
 {code}
   /**
* Used by SkinStyleProvider to decide whether to cache the StyleProvider 
 or not.
* @return true if skin is internal to the framework.
*/
   public abstract boolean isCacheable();
 {code}
 In SkinExtension introduce overloaded constructor for handling internal Skin 
 creation and external Skin creation (through SkinFactory.createSkin)
 {code}
   /**
* Creates SkinExtension from SkinMetadata and base Skin
* This constructor is used for creating skins for external SkinProvider 
 implementations.
* We keep skins thus created as not-cacheable.
* @see org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl
* @param baseSkin
* @param skinMetadata
*/
   public SkinExtension(Skin baseSkin, SkinMetadata skinMetadata)
   {
 this(baseSkin, skinMetadata, false);
   }
   /**
* Creates SkinExtension from SkinMetadata, base Skin and cacheability
* This constructor is used only for INTERNAL skins
* @see 
 org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider
* @param baseSkin
* @param skinMetadata
*/
   public SkinExtension(Skin baseSkin, SkinMetadata skinMetadata, boolean 
 isCacheable)
   {
 // existing code:
 // read values from skinMetadata and set
 _isCacheable = isCacheable;
   }
 {code}
 Check SkinImpl.isCacheable() before caching the StyleProvider.
 For solving the concurrency issue in LRU cache used for caching 
 StyleProviders, introduce new CopyOnWriteArrayMap and use it.
 For testing add SkinProvider test cases, CopyOnWriteArrayMap test cases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TRINIDAD-2509) For date pattern=yyyy:DDD HH:mm:ss, validation error is thrown even when the date is selected from popup and is correct

2014-10-10 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166687#comment-14166687
 ] 

Andy Schwartz commented on TRINIDAD-2509:
-

Checked in the updated version of the patch at r1630638.

 For date pattern=:DDD HH:mm:ss, validation error is thrown even when the 
 date is selected from popup and is correct
 ---

 Key: TRINIDAD-2509
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2509
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
 Environment: Issue occurs on all platforms
Reporter: Anshu Jain
 Fix For: 2.1.1-core

 Attachments: TRINIDAD-2509.patch, TRINIDAD-2509_1.patch


 For a date component, the pattern is set to :DDD HH:mm:ss.
 On opening the calendar popup and selecting a date, a validation error is 
 thrown:
 Error: The date or time entered is not valid.
 The date in the date filed is in correct format at this time. But, the 
 validation error is incorrectly thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TRINIDAD-2510) make SkinTestCase more extendable

2014-10-09 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2510:

   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

Committed fix in r1630639.

 make SkinTestCase more extendable
 -

 Key: TRINIDAD-2510
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2510
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.1-core

 Attachments: jira-2510-modified.patch, jira-2510-new.patch, 
 jira-2510.patch


 SkinTestCase which is part of trinidad-impl/test, works with TestSkin enum 
 which does not offer flexibility. The change proposed is to add an overloaded 
 method for visiting skins where the skin resource path can be passed as a 
 String. This will enable test cases extending SkinTestCase to work with any 
 skin of their choice.
 The proposed change is to add this method in SkinTestCase:
   /**
* Performs a visit of all style sheet nodes in the specified test
* skin. This overloaded method is useful in extending SkinTestCase to
* create more test cases since TestSkin does not provide all the skins
* that test needs.
*/
   protected final void visitStyleSheets(String skinResourcePath, 
 StyleSheetVisitor visitor)
   {
 StyleSheetDocument document = SkinTestUtils.parseSkin(skinResourcePath);
 
 StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
 visitor);
   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TRINIDAD-2513) NullpointException running Trinidad with Tomcat 8

2014-10-09 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166175#comment-14166175
 ] 

Andy Schwartz commented on TRINIDAD-2513:
-

Seems like this might be the same issue as TRINIDAD-2483.

 NullpointException running Trinidad with Tomcat 8
 -

 Key: TRINIDAD-2513
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2513
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
 Environment: Tomcat 8
Reporter: Pervasync
Priority: Blocker

 We have a Apache Trinidad based app that runs fine with Tomcat 6 and 7. The 
 same app throws the following exception on Tomcat 8. Trinidad lib version was 
 2.1.0 and MyFaces lib version was 2.1.16.
 org.apache.jasper.JasperException: An exception occurred processing JSP page 
 /login.jspx at line 14
 11: link rel=shortcut icon 
 href=/pervasync/images/pvs_logo_32_32.ico/
 12: /trh:head
 13: trh:body
 14: tr:document title=...
 15: head
 16: link rel=shortcut icon type=image/png 
 href=/pervasync/images/pvs_logo_32_32.png/
 17: /head
 Stacktrace:
 at 
 org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:568)
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:470)
 at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:335)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 ...
 Caused by: java.lang.NullPointerException
 at 
 org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:113)
 at 
 org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty(UIXComponentELTag.java:297)
 at 
 org.apache.myfaces.trinidadinternal.taglib.core.CoreDocumentTag.setProperties(CoreDocumentTag.java:179)
 at 
 org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperties(UIXComponentELTag.java:284)
 at 
 javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:98)
 at 
 org.apache.myfaces.trinidad.webapp.UIXComponentELTag.createComponent(UIXComponentELTag.java:223)
 at 
 javax.faces.webapp.UIComponentClassicTagBase.findComponent(UIComponentClassicTagBase.java:1195)
 at 
 javax.faces.webapp.UIComponentClassicTagBase.doStartTag(UIComponentClassicTagBase.java:514)
 at 
 org.apache.myfaces.trinidad.webapp.UIXComponentELTag.doStartTag(UIXComponentELTag.java:113)
 at 
 org.apache.jsp.login_jspx._jspx_meth_tr_005fdocument_005f0(login_jspx.java:282)
 at 
 org.apache.jsp.login_jspx._jspx_meth_trh_005fbody_005f0(login_jspx.java:250)
 at 
 org.apache.jsp.login_jspx._jspx_meth_trh_005fhtml_005f0(login_jspx.java:175)
 at 
 org.apache.jsp.login_jspx._jspx_meth_f_005fview_005f0(login_jspx.java:135)
 at org.apache.jsp.login_jspx._jspService(login_jspx.java:96)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
 ... 56 more



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TRINIDAD-2510) make SkinTestCase more extendable

2014-10-08 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14163900#comment-14163900
 ] 

Andy Schwartz commented on TRINIDAD-2510:
-

Since this is in trinidadinternal, I think it is fine to tweak these protected 
methods.  Let's change the getSkinDocument() hook to take the resource name 
String instead of TestSkin.


 make SkinTestCase more extendable
 -

 Key: TRINIDAD-2510
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2510
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
 Attachments: jira-2510-modified.patch, jira-2510.patch


 SkinTestCase which is part of trinidad-impl/test, works with TestSkin enum 
 which does not offer flexibility. The change proposed is to add an overloaded 
 method for visiting skins where the skin resource path can be passed as a 
 String. This will enable test cases extending SkinTestCase to work with any 
 skin of their choice.
 The proposed change is to add this method in SkinTestCase:
   /**
* Performs a visit of all style sheet nodes in the specified test
* skin. This overloaded method is useful in extending SkinTestCase to
* create more test cases since TestSkin does not provide all the skins
* that test needs.
*/
   protected final void visitStyleSheets(String skinResourcePath, 
 StyleSheetVisitor visitor)
   {
 StyleSheetDocument document = SkinTestUtils.parseSkin(skinResourcePath);
 
 StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
 visitor);
   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TRINIDAD-2510) make SkinTestCase more extendable

2014-10-06 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160868#comment-14160868
 ] 

Andy Schwartz commented on TRINIDAD-2510:
-

Thanks for the patch.  I see that this introduces a new protected (final) 
method:

  /**
   * Performs a visit of all style sheet nodes in the specified test
   * skin. This overloaded method is useful in extending SkinTestCase to
   * create more test cases since TestSkin does not provide all the skins
   * that test needs.
   */
  protected final void visitStyleSheets(String skinResourcePath, 
StyleSheetVisitor visitor)
  {
StyleSheetDocument document = SkinTestUtils.parseSkin(skinResourcePath);

StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
visitor);
  }

That is an overload of this protected method that is already present:

  /**
   * Performs a visit of all style sheet nodes in the specified test
   * skin
   */
  protected void visitStyleSheets(TestSkin testSkin, StyleSheetVisitor visitor)
  {
StyleSheetDocument document = getSkinDocument(testSkin);

StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
visitor);
  }

The new protected method that takes the String resource path looks like the 
more primitive method, and thus would make more sense as the non-final hook.

What do you think about doing this:

1.  Change the old TestSkin-based method such that it looks up its resource 
path and then calls the new String-based method with this value.
2.  Make the old TestSkin-based method final.
3.  Make the new String-based method non-final.

This also has the nice side effect of avoiding the duplicate call to 
StyleSheetVisitUtils.visitStyleSheets().

 make SkinTestCase more extendable
 -

 Key: TRINIDAD-2510
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2510
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
 Attachments: jira-2510-modified.patch, jira-2510.patch


 SkinTestCase which is part of trinidad-impl/test, works with TestSkin enum 
 which does not offer flexibility. The change proposed is to add an overloaded 
 method for visiting skins where the skin resource path can be passed as a 
 String. This will enable test cases extending SkinTestCase to work with any 
 skin of their choice.
 The proposed change is to add this method in SkinTestCase:
   /**
* Performs a visit of all style sheet nodes in the specified test
* skin. This overloaded method is useful in extending SkinTestCase to
* create more test cases since TestSkin does not provide all the skins
* that test needs.
*/
   protected final void visitStyleSheets(String skinResourcePath, 
 StyleSheetVisitor visitor)
   {
 StyleSheetDocument document = SkinTestUtils.parseSkin(skinResourcePath);
 
 StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
 visitor);
   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TRINIDAD-2509) For date pattern=yyyy:DDD HH:mm:ss, validation error is thrown even when the date is selected from popup and is correct

2014-10-01 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2509:

   Resolution: Fixed
Fix Version/s: 2.1.1-core
   Status: Resolved  (was: Patch Available)

Committed fix in r1628732.

 For date pattern=:DDD HH:mm:ss, validation error is thrown even when the 
 date is selected from popup and is correct
 ---

 Key: TRINIDAD-2509
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2509
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
 Environment: Issue occurs on all platforms
Reporter: Anshu Jain
 Fix For: 2.1.1-core

 Attachments: TRINIDAD-2509.patch


 For a date component, the pattern is set to :DDD HH:mm:ss.
 On opening the calendar popup and selecting a date, a validation error is 
 thrown:
 Error: The date or time entered is not valid.
 The date in the date filed is in correct format at this time. But, the 
 validation error is incorrectly thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TRINIDAD-2511) rounding mode is not honoured on the client while using number converter

2014-10-01 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2511:

   Resolution: Fixed
Fix Version/s: 2.1.1-core
   Status: Resolved  (was: Patch Available)

Fixed in r1628735.

 rounding mode is not honoured on the client while using number converter
 

 Key: TRINIDAD-2511
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2511
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Ashwin Prabhu
 Fix For: 2.1.1-core

 Attachments: TRINIDAD-2511.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 When rounding mode is specified on af:convertNumber, decimal truncation 
 affected by min/max fraction digits should be governed by the rounding mode 
 specified. 
 Currently client side number converter (TrNumberConverter) performs decimal 
 truncation when maxFractionDigits is specified without considering the 
 rounding mode chosen. This leads to data inconsistencies when 
 af:convertNumber is attached to input components. 
 For ex:
 tr:inputText label=Label 1 id=it1 
 tr:convertNumber type=number  roundingMode=UP maxFractionDigits=2/ 
 /tr:inputText 
 the above converts 5.551 to 5.55, wheras the correct rounding should have 
 been 5.56, since the rounding mode is UP.
 However, since he server side converter correctly implements rounding, the 
 issue does not arise when the converter is attached to output components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TRINIDAD-2510) make SkinTestCase more extendable

2014-10-01 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154943#comment-14154943
 ] 

Andy Schwartz commented on TRINIDAD-2510:
-

On applying the patch, I see this output:

patch -p0 -i ~/patches/jira-2510.patch 
(Stripping trailing CRs from patch.)
patching file 
trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/skin/SkinTestCase.java
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 76 with fuzz 2.

The patch unexpectedly ends in middle of line message makes me worried that 
something might be wrong.  Can you double-check that the patch is correct 
and/or provide a new patch that does not show this message when applied to the 
Trinidad trunk?

 make SkinTestCase more extendable
 -

 Key: TRINIDAD-2510
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2510
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
 Attachments: jira-2510.patch


 SkinTestCase which is part of trinidad-impl/test, works with TestSkin enum 
 which does not offer flexibility. The change proposed is to add an overloaded 
 method for visiting skins where the skin resource path can be passed as a 
 String. This will enable test cases extending SkinTestCase to work with any 
 skin of their choice.
 The proposed change is to add this method in SkinTestCase:
   /**
* Performs a visit of all style sheet nodes in the specified test
* skin. This overloaded method is useful in extending SkinTestCase to
* create more test cases since TestSkin does not provide all the skins
* that test needs.
*/
   protected final void visitStyleSheets(String skinResourcePath, 
 StyleSheetVisitor visitor)
   {
 StyleSheetDocument document = SkinTestUtils.parseSkin(skinResourcePath);
 
 StyleSheetVisitUtils.visitStyleSheets(document.getStyleSheetsAsCollection(), 
 visitor);
   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TRINIDAD-2508) JSF 2.2 @MultipartConfig on FacesServlet breaks Trinidad file upload

2014-09-11 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2508:
---

 Summary: JSF 2.2 @MultipartConfig on FacesServlet breaks Trinidad 
file upload
 Key: TRINIDAD-2508
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2508
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Andy Schwartz
Assignee: Andy Schwartz


I have been testing Trinidad against JSF 2.2.  So far everything looks good 
with one exception:  Trinidad's file upload feature is broken.

I traced this down to a conflict between Java EE's multipart form support and 
Trinidad file upload.  Both Java EE and Trinidad are capable of processing 
multipart forms.  However, the multipart request input stream can only be read 
once, which means that only one layer gets to do this work.

Trinidad processes multipart forms in its FileUploadConfiguratorImpl, which is 
run from inside TrinidadFilterImpl.doFilter().  However, when running against 
JSF 2.2, the servlet engine (WLS in my case) is reading the request input 
stream before we get this far.  I found that this was happening in response to 
servlet request parameter lookups that are made by other Configurators.

The change in behavior from JSF 2.1 to JSF 2.2 is this:  prior to JSF 2.2 - and 
specifically, prior to the introduction of the @MultipartConfig annotation to 
FacesServlet, request parameter lookups that are made before the 
FileUploadConfiguratorImpl processes the multipart data would fail - ie. would 
return null without reading the request input stream.

After upgrading to JSF 2.2, the presence of the @MultipartConfig now tells the 
servlet engine that it is responsible for reading multipart form data.  Thus, 
request parameter lookups which previously behaved as no-ops are now causing 
the request input stream to be read.  As a result, by the time 
FileUploadConfiguratorImpl is invoked, there is no data left on the request 
input stream and Trinidad does not recognize that there are uploaded files.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TRINIDAD-2499) ChangeManager provides incorrect document location for dynamic components

2014-08-14 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2499:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

Fixed in r1617943.  Thanks Prakash!

 ChangeManager provides incorrect document location for dynamic components
 -

 Key: TRINIDAD-2499
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2499
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.1.0-core
Reporter: Prakash Udupa
Assignee: Andy Schwartz
 Fix For: 2.1.1-core

 Attachments: TRINIDAD-2499.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 In TRINIDAD-2397, enhancement was provided to obtain the document location of 
 components are are dynamically added. There is a bug in this code that in 
 some cases the location is not provided correctly, as explained in the 
 following example:
 Consider this page structure:
 jsp:root
   foo:three
 foo:insertingComponent = Step #2: This subtree is inserted from 
 fragment2.jsff
   jsp:root
 foo:dynamicLayout
   foo:two = Step #1: defined in fargment1.jsff
 foo:one = Customization target, this inserted component is 
 defined in fragment1.jsff
 In this example, the search for location is expected to stop at step #1 and 
 location returned as 'fragment1.jsff', instead the look up extends until step 
 #2 and returns incorrect location 'fragment2.jsff'.
 This causes the wrong document being searched for the customization target 
 here, customization failed therefore.
 The bug is in 
 org.apache.myfaces.trinidad.util.ComponentUtils.getDocumentLocationForComponent()
 Will provide a fix patch soon.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2488) NPE in TrinidadSkinProvider when base skin is not included in skin def in trinidad-skins.xml

2014-06-27 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2488:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

Committed in r1606219.

Thanks for the fix Prakash!

 NPE in TrinidadSkinProvider when base skin is not included in skin def in 
 trinidad-skins.xml
 

 Key: TRINIDAD-2488
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2488
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Prakash Udupa
Assignee: Andy Schwartz
 Fix For: 2.1.1-core

 Attachments: TRINIDAD-2488.trunk.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 In our application, we encountered this NPE, whenever base skin is not 
 mentioned in the skin definition in trinidad-skins.xml (trivial to build a 
 test-case thus). This needs to be fixed, because Trinidad framework is 
 supposed to assume the default base skin based on renderkit or otherwise 
 default to Trinidad's simple.desktop skin.
 ==
 # java.lang.NullPointerException
 #  at
 org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider.loadAvailableSkin(TrinidadSkinProvider.java:163)
 #  at
 org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider._getMatchingSkin(BaseSkinProvider.java:216)
 #  at
 org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider.getSkin(BaseSkinProvider.java:60)
 #  at
 org.apache.myfaces.trinidadinternal.skin.provider.SkinProviderRegistry.getSkin(SkinProviderRegistry.java:116)
 #  at
 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:635)
 #  at
 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.init(CoreRenderingContext.java:89)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2486) SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS ON

2014-06-25 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2486:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

Committed the fix in r1605316.

 SELECTOR OF KIND IMG[SRC*=/ADF/IMAGES/T.GIF] BREAKS IF SKIN COMPRESSION IS 
 ON
 ---

 Key: TRINIDAD-2486
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2486
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Andy Schwartz
 Fix For: 2.1.1-core

 Attachments: jira-2486-on-trunk.patch


 With selector of kind X[attr = foo.gif] is used and skin compression is on, 
 the generated css is malformed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TRINIDAD-2484) Threadsafety issue in SkinStyleProvider leading to missing styles and distorted ui

2014-06-23 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz resolved TRINIDAD-2484.
-

Resolution: Fixed
Fix Version/s: 2.1.1-core
Assignee: Andy Schwartz

Committed in r1604869.

Thanks for the fix, Prakash!

Threadsafety issue in SkinStyleProvider leading to missing styles and
distorted ui
--

Key: TRINIDAD-2484
URL: https://issues.apache.org/jira/browse/TRINIDAD-2484
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Prakash Udupa
Assignee: Andy Schwartz
Fix For: 2.1.1-core

Attachments: TRINIDAD-2484-trunk.patch

Original Estimate: 24h
Remaining Estimate: 24h

We have seen that soon after server start, when there are almost concurrent
requests from IE, in random occurrences, there will be only one link encoded
in the HTML, while there are two css files generated. Consequently, styles
for some components in the page could go missing, ending up in distorted UI
in certain sections of the rendered page.
We suspect the cause to be a thread safety issue in SkinStyleProvider
implementation where we construct style providers and save it in map keyed by
skin and the directory path of the css. The issue is in _getProviders()
implementation, where the variable _sSharedProviders is not accessed in
threadsafe manner. This leads to possibility of the providers map being
overwritten. This further leads to constructing two SkinStyleProviders for
the same skin. While one request could use one provider (P1) that is in
process of writing out one css file with the second one pending, there could
be other request that ends up using a different provider (P2) that would see
a single file written, and end up adding single URI in its Entry map. All
requests later could end up using P2 and sufferring from only one link being
rendered, while there are two stylesheets actually generated.
Proposed fix is to eliminate _sSharedProviders, and instead use the
application scoped concurrent map hanging off of request scope to store the
provider map. We can then leverage on the putIfAbsent in there to ensure
there is only one copy of providers map for an application.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (TRINIDAD-2478) FileSystemStyleCache file modification checking not working

2014-06-03 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz resolved TRINIDAD-2478.
-

   Resolution: Fixed
Fix Version/s: 2.1.1-core

Committed fix in r1599782.

 FileSystemStyleCache file modification checking not working
 ---

 Key: TRINIDAD-2478
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2478
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.1.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Trivial
 Fix For: 2.1.1-core


 I introduced a minor regression in my fix for Trinidad-2468.  
 The bug is here:
  FutureEntry f = cache.get(key);
  Entry entry = _getEntryFromFuture(context, document, cache, key, f);
  if ((entry != null)  !_validateEntry(entry, checkModified))
  {
// atomically remove the key from the cache if it currently points to 
  the entry
cache.remove(key, entry);
entry = null;
  }
 The cache.remove() call should be removing the Future, not the Entry.  So:
cache.remove(key, entry);
 Should be:
cache.remove(key, f);
 The impact of this bug is that, when 
 org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION is enabled, we won't 
 actually clear out our in-memory cache, and won't re-generate the .css files, 
 if we detect that the generated .css files have been blown away out from 
 under us.  A server bounce is now required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TRINIDAD-2478) FileSystemStyleCache file modification checking not working

2014-05-30 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2478:
---

 Summary: FileSystemStyleCache file modification checking not 
working
 Key: TRINIDAD-2478
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2478
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.1.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Trivial


I introduced a minor regression in my fix for Trinidad-2468.  

The bug is here:

 FutureEntry f = cache.get(key);
 Entry entry = _getEntryFromFuture(context, document, cache, key, f);
 if ((entry != null)  !_validateEntry(entry, checkModified))
 {
   // atomically remove the key from the cache if it currently points to 
 the entry
   cache.remove(key, entry);
   entry = null;
 }

The cache.remove() call should be removing the Future, not the Entry.  So:

   cache.remove(key, entry);

Should be:

   cache.remove(key, f);

The impact of this bug is that, when 
org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION is enabled, we won't 
actually clear out our in-memory cache, and won't re-generate the .css files, 
if we detect that the generated .css files have been blown away out from under 
us.  A server bounce is now required.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2476) MApplication.java needs to override subscribeToEvent

2014-05-27 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14009650#comment-14009650
 ] 

Andy Schwartz commented on TRINIDAD-2476:
-

Committed fix in r1597776.  Thanks Kevin.

 MApplication.java needs to override subscribeToEvent
 

 Key: TRINIDAD-2476
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2476
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Kevin Jackson
 Fix For: 2.1.1-core

 Attachments: MApplication.java.diff, trinidad-2476-take2.patch


 The ADF unit tests fails with JSF 2.2 without override of subscribeToEvent



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2476) MApplication.java needs to override subscribeToEvent

2014-05-27 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2476:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

 MApplication.java needs to override subscribeToEvent
 

 Key: TRINIDAD-2476
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2476
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Kevin Jackson
Assignee: Andy Schwartz
 Fix For: 2.1.1-core

 Attachments: MApplication.java.diff, trinidad-2476-take2.patch


 The ADF unit tests fails with JSF 2.2 without override of subscribeToEvent



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TRINIDAD-2476) MApplication.java needs to override subscribeToEvent

2014-05-23 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14007661#comment-14007661
 ] 

Andy Schwartz edited comment on TRINIDAD-2476 at 5/23/14 8:31 PM:
--

This patch:

https://issues.apache.org/jira/secure/attachment/12646593/trinidad-2476-take2.patch

Adds a little clean up on top of Kevin's patch.  Reformatted some method 
parameter lists, added a little comment, move the subscribe/unsubscribe methods 
next to the existing publish event methods.


was (Author: andy.schwartz):
Just a little clean up on top of Kevin's patch.  Reformatted some method 
parameter lists, added a little comment, move the subscribe/unsubscribe methods 
next to the existing publish event methods.

 MApplication.java needs to override subscribeToEvent
 

 Key: TRINIDAD-2476
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2476
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Kevin Jackson
 Attachments: MApplication.java.diff, trinidad-2476-take2.patch


 The ADF unit tests fails with JSF 2.2 without override of subscribeToEvent



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-05-16 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998869#comment-13998869
]

Andy Schwartz commented on TRINIDAD-2468:
-

This is a new version of the fix:

https://issues.apache.org/jira/secure/attachment/12645030/trinidad-2468-take3.patch

That modifies the case where FileSystemStyleCache._createEntry() fails because
there are no matching style nodes found.

Before my fix, this failed silently.

In the first two versions of my fix, this fails with a NullPointerException.

After discussing with Blake, we decided that it is best to make this case fail
in a more obvious way. This now fails with an IllegalStateException with a
more useful error message.

FileSystemStyleCache: split style sheet concurrency issue
-

Key: TRINIDAD-2468
URL: https://issues.apache.org/jira/browse/TRINIDAD-2468
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Attachments: trinidad-2468-hack-delays-on-top-of-fix.patch,
trinidad-2468-hack-delays.patch, trinidad-2468-take2.patch,
trinidad-2468-take3.patch, trinidad-2468.patch

Due to IE’s per-file style rule limit, documented here:

http://support.microsoft.com/kb/262161
In particular:
“All style rules after the first 4,095 rules are not applied.”
Trinidad’s skinning framework breaks up large style sheets into multiple
files, each with a maximum of 4,095 rules. That is, a generated style sheet
of the form:
- foo-desktop-gecko.css
Might be result in the generation of two style sheets on IE:
- foo-desktop-ie.css
- foo-desktop-ie2.css
We are running into thread safety problems with the current implementation of
this multi-file solution.
Under certain circumstances, we see the style sheet (correctly) being split
across two files, but only a single style sheet link is rendered in the HTML
contents. As a result, the styles from the second file are missing, which
typically has fatal results.
This only happens under a somewhat unusual case: the client who is reporting
this behavior is running a test which upon start up immediately hits the
server with two concurrent requests from IE.
This triggers the following sequence:
- Request 1 enters FileSystemStyleCache._createEntry().
- Request 1 generates the first of two files that make up the IE-specific
style sheet.
- Request 2 arrives and, finding FileSystemStyleCache’s entry cache empty,
also enters _createEntry().
- Upon entry to _createEntry(), Request 2 checks to see whether any files
have already been generated for the requested style sheet.
- Request 2 finds the first of two files and assumes that the style sheet is
composed of a single file.
- Request 1 finishes generating the second style sheet.
- Request 1 populates the FileSystemStyleCache’s entry cache with an Entry
instance that correctly references both generated files.
- Request 2 blows away the previously installed Entry and replaces it with a
bogus Entry that only references the first of two style sheet files.
On all subsequent requests, StyleSheetRenderer retrieves data from the bogus
(single file) Entry, and thus only renders a single link.
The fix is to control access to _createEntry() for individual style sheets.
That is, we want to allow concurrent access to _createEntry() for style
sheets with different variants (ie. it should be possible to generate the IE
style sheets and Gecko style sheets concurrently). However, if a request is
in the middle of generating files for a particular style sheet, other
requests that want access to the same style sheet must wait until the first
request completes its work (instead of possibly trampling over the work of
the first request).

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-16 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970674#comment-13970674
]

Andy Schwartz commented on TRINIDAD-2468:
-

I have put together a patch file that can be applied to trinidad-trunk to help
simulate the problem:

https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch

This patch does the following:

- Introduces a delay after the first file of a two part style sheet is written.
- Introduces a second delay when a second request detects that a single file is
present on the file system.
- Tweaks our logic for deciding when to split style sheet files to make it
easier to hit the split style sheet file case.
- Adds logging that includes the thread id.

We can now simulate the problem by:

1. Applying the patch to trinidad-trunk.
2. Fire up trinidad-demo
3. Make sure that the trinidad-demo’s style sheet cache is empty.
4. Hit the demo via curl, eg:

curl localhost:8080/trinidad-demo/faces/index.jspx

5. Wait a few seconds, and then hit the demo a second time via curl.

Without the fix, we see the following sequence:

SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
{thread:12}
SEVERE: !! I have written one output file. Going to sleep for a while.
{thread:12}
SEVERE: !! Entering _createEntry {thread:16}
SEVERE: !! I found one output file. Going to sleep for a while! {thread:16}
SEVERE: !! Done sleeping. Ready write more output files. {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
{thread:12}
SEVERE: !! Exiting _createEntry. Entry now has 2 file(s) {thread:12}
SEVERE: !! Just one output file here. Waking up. {thread:16}
SEVERE: !! Got output files: 1 {thread:16}
SEVERE: !! Exiting _createEntry. Entry now has 1 file(s) {thread:16}

At this point the entry cache contains an Entry instance with a single file
reference, even though two files were written. All requests from here on out
result in a single style sheet link being rendered.

I have also uploaded a second patch that can be applied on top of my fix
(required some tweaking):

https://issues.apache.org/jira/secure/attachment/12640453/trinidad-2468-hack-delays-on-top-of-fix.patch

When running the same steps against the fix, we now see output like this:

SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
{thread:12}
SEVERE: !! I have written one output file. Going to sleep for a while.
{thread:12}
SEVERE: !! Getting entry from Future {thread:16}
SEVERE: !! Done sleeping. Ready write more output files. {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
{thread:12}
SEVERE: !! Exiting _createEntry. Entry now has 2 file(s) {thread:12}
SEVERE: !! Got entry with 2 file(s) from Future {thread:16}
SEVERE: !! Got entry with 2 file(s) from Future {thread:12}

The second thread now waits on Future.get() until the first thread has
completed generating both style sheets. And now everyone has a consistent view
of the world.

FileSystemStyleCache: split style sheet concurrency issue
-

Due to IE’s per-file style rule limit, documented here:

[jira] [Comment Edited] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-16 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970674#comment-13970674
 ] 

Andy Schwartz edited comment on TRINIDAD-2468 at 4/16/14 11:15 AM:
---

I have put together a patch file that can be applied to trinidad-trunk to help 
simulate the problem:

https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch

This patch does the following:

- Introduces a delay after the first file of a two part style sheet is written.
- Introduces a second delay when a second request detects that a single file is 
present on the file system.
- Tweaks our logic for deciding when to split style sheet files to make it 
easier to hit the split style sheet file case.
-  Adds logging that includes the thread id.

We can now simulate the problem by:

1.  Applying the patch to trinidad-trunk.
2.  Fire up trinidad-demo
3.  Make sure that the trinidad-demo’s style sheet cache is empty.
4.  Hit the demo via curl, eg:

curl localhost:8080/trinidad-demo/faces/index.jspx

5.  Wait a few seconds, and then hit the demo a second time via curl.

Without the fix, we see the following sequence:

{noformat}
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file: 
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
 {thread:12}
SEVERE: !! I have written one output file.  Going to sleep for a while. 
{thread:12}
SEVERE: !! Entering _createEntry {thread:16}
SEVERE: !! I found one output file.  Going to sleep for a while! {thread:16}
SEVERE: !! Done sleeping.  Ready write more output files. {thread:12}
SEVERE: !! Creating output file: 
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
 {thread:12}
SEVERE: !! Exiting _createEntry.  Entry now has 2 file(s) {thread:12}
SEVERE: !! Just one output file here.  Waking up. {thread:16}
SEVERE: !! Got output files: 1 {thread:16}
SEVERE: !! Exiting _createEntry.  Entry now has 1 file(s) {thread:16}
{noformat}

At this point the entry cache contains an Entry instance with a single file 
reference, even though two files were written.  All requests from here on out 
result in a single style sheet link being rendered.

I have also uploaded a second patch that can be applied on top of my fix 
(required some tweaking):

https://issues.apache.org/jira/secure/attachment/12640453/trinidad-2468-hack-delays-on-top-of-fix.patch

When running the same steps against the fix, we now see output like this:

{noformat}
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file: 
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
 {thread:12}
SEVERE: !! I have written one output file.  Going to sleep for a while. 
{thread:12}
SEVERE: !! Getting entry from Future {thread:16}
SEVERE: !! Done sleeping.  Ready write more output files. {thread:12}
SEVERE: !! Creating output file: 
/scratch/anschwar/dev/trinidad/trinidad-2468-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
 {thread:12}
SEVERE: !! Exiting _createEntry.  Entry now has 2 file(s) {thread:12}
SEVERE: !! Got entry with 2 file(s) from Future {thread:16}
SEVERE: !! Got entry with 2 file(s) from Future {thread:12}
{noformat}

The second thread now waits on Future.get() until the first thread has 
completed generating both style sheets.  And now everyone has a consistent view 
of the world.


was (Author: andy.schwartz):
I have put together a patch file that can be applied to trinidad-trunk to help 
simulate the problem:

https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch

This patch does the following:

- Introduces a delay after the first file of a two part style sheet is written.
- Introduces a second delay when a second request detects that a single file is 
present on the file system.
- Tweaks our logic for deciding when to split style sheet files to make it 
easier to hit the split style sheet file case.
-  Adds logging that includes the thread id.

We can now simulate the problem by:

1.  Applying the patch to trinidad-trunk.
2.  Fire up trinidad-demo
3.  Make sure that the trinidad-demo’s style sheet cache is empty.
4.  Hit the demo via curl, eg:

curl localhost:8080/trinidad-demo/faces/index.jspx

5.  Wait a few seconds, and then hit the demo a second time via curl.

Without the fix, we see the following sequence:

{noformat}
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}

[jira] [Comment Edited] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-16 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970674#comment-13970674
]

Andy Schwartz edited comment on TRINIDAD-2468 at 4/16/14 11:15 AM:
---

I have put together a patch file that can be applied to trinidad-trunk to help
simulate the problem:

https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch

This patch does the following:

We can now simulate the problem by:

1. Applying the patch to trinidad-trunk.
2. Fire up trinidad-demo
3. Make sure that the trinidad-demo’s style sheet cache is empty.
4. Hit the demo via curl, eg:

curl localhost:8080/trinidad-demo/faces/index.jspx

5. Wait a few seconds, and then hit the demo a second time via curl.

Without the fix, we see the following sequence:

{noformat}
SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u.css
{thread:12}
SEVERE: !! I have written one output file. Going to sleep for a while.
{thread:12}
SEVERE: !! Entering _createEntry {thread:16}
SEVERE: !! I found one output file. Going to sleep for a while! {thread:16}
SEVERE: !! Done sleeping. Ready write more output files. {thread:12}
SEVERE: !! Creating output file:
/scratch/anschwar/dev/trinidad/trinidad-trunk/trinidad-examples/trinidad-demo/target/work/adf/styles/cache/casablanca-desktop-mjyt4t--d-d-d-d-ltr-d--s-n-u2.css
{thread:12}
SEVERE: !! Exiting _createEntry. Entry now has 2 file(s) {thread:12}
SEVERE: !! Just one output file here. Waking up. {thread:16}
SEVERE: !! Got output files: 1 {thread:16}
SEVERE: !! Exiting _createEntry. Entry now has 1 file(s) {thread:16}
{noformat}

I have also uploaded a second patch that can be applied on top of my fix
(required some tweaking):

https://issues.apache.org/jira/secure/attachment/12640453/trinidad-2468-hack-delays-on-top-of-fix.patch

When running the same steps against the fix, we now see output like this:

The second thread now waits on Future.get() until the first thread has
completed generating both style sheets. And now everyone has a consistent view
of the world.

was (Author: andy.schwartz):
I have put together a patch file that can be applied to trinidad-trunk to help
simulate the problem:

https://issues.apache.org/jira/secure/attachment/12640452/trinidad-2468-hack-delays.patch

This patch does the following:

We can now simulate the problem by:

1. Applying the patch to trinidad-trunk.
2. Fire up trinidad-demo
3. Make sure that the trinidad-demo’s style sheet cache is empty.
4. Hit the demo via curl, eg:

curl localhost:8080/trinidad-demo/faces/index.jspx

5. Wait a few seconds, and then hit the demo a second time via curl.

Without the fix, we see the following sequence:

SEVERE: !! Entering _createEntry {thread:12}
SEVERE: !! Got output files: 0 {thread:12}
SEVERE: !! Creating output file:

[jira] [Commented] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-16 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13971531#comment-13971531
]

Andy Schwartz commented on TRINIDAD-2468:
-

Uploaded a new version of the fix:

https://issues.apache.org/jira/secure/attachment/12640471/trinidad-2468-take2.patch

That includes some minor InterruptedException handling tweaks.

FileSystemStyleCache: split style sheet concurrency issue
-

Due to IE’s per-file style rule limit, documented here:

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-15 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2468:
---

 Summary: FileSystemStyleCache: split style sheet concurrency issue
 Key: TRINIDAD-2468
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2468
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Andy Schwartz
Assignee: Andy Schwartz


Due to IE’s per-file style rule limit, documented here:

http://support.microsoft.com/kb/262161

In particular:

“All style rules after the first 4,095 rules are not applied.”

Trinidad’s skinning framework breaks up large style sheets into multiple files, 
each with a maximum of 4,095 rules.  That is, a generated style sheet of the 
form:

-  foo-desktop-gecko.css

Might be result in the generation of two style sheets on IE:

-  foo-desktop-ie.css
-  foo-desktop-ie2.css

We are running into thread safety problems with the current implementation of 
this multi-file solution.

Under certain circumstances, we see the style sheet (correctly) being split 
across two files, but only a single style sheet link is rendered in the HTML 
contents.  As a result, the styles from the second file are missing, which 
typically has fatal results.

This only happens under a somewhat unusual case: the client who is reporting 
this behavior is running a test which upon start up immediately hits the server 
with two concurrent requests from IE.

This triggers the following sequence:

- Request 1 enters FileSystemStyleCache._createEntry().
- Request 1 generates the first of two files that make up the IE-specific style 
sheet.
- Request 2 arrives and, finding FileSystemStyleCache’s entry cache empty, also 
enters _createEntry().
- Upon entry to _createEntry(), Request 2 checks to see whether any files have 
already been generated for the requested style sheet.
- Request 2 finds the first of two files and assumes that the style sheet is 
composed of a single file.
- Request 1 finishes generating the second style sheet.
- Request 1 populates the FileSystemStyleCache’s entry cache with an Entry 
instance that correctly references both generated files.
- Request 2 blows away the previously installed Entry and replaces it with a 
bogus Entry that only references the first of two style sheet files.

On all subsequent requests, StyleSheetRenderer retrieves data from the bogus 
(single file) Entry, and thus only renders a single link.

The fix is to control access to _createEntry() for individual style sheets.  
That is, we want to allow concurrent access to _createEntry() for style sheets 
with different variants (ie. it should be possible to generate the IE style 
sheets and Gecko style sheets concurrently).  However, if a request is in the 
middle of generating files for a particular style sheet, other requests that 
want access to the same style sheet must wait until the first request completes 
its work (instead of possibly trampling over the work of the first request).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-15 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2468:

Status: Patch Available (was: Open)

FileSystemStyleCache: split style sheet concurrency issue
-

Due to IE’s per-file style rule limit, documented here:

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2468) FileSystemStyleCache: split style sheet concurrency issue

2014-04-15 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970350#comment-13970350
]

Andy Schwartz commented on TRINIDAD-2468:
-

The provided patch:

https://issues.apache.org/jira/secure/attachment/12640377/trinidad-2468.patch

Fixes the thread safety issues by converting the FileSystemStyleCache's entry
cache over to the efficient, scalable result cache solution described in JCIP
section 5.6. This solution uses Future instances as cache entries to constrain
access to each entry value. The first request into the cache for a particular
key puts a Future instance into the cache and then kicks off the computation of
the Future's value. (In FileSystemStyleCache's case, this includes generating
the files corresponding to the cache entry.) Each subsequent cache access is
routed through a call to Future.get(), which will block until the Future's
value is computed.

Requests for other cache entries can happily proceed in parallel. As a result,
we get thread-safety on a per-entry basis with no loss of concurrency across
entries.

FileSystemStyleCache: split style sheet concurrency issue
-

Due to IE’s per-file style rule limit, documented here:

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TRINIDAD-2463) Concurrency issues in CachingResourceLoader

2014-03-25 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2463:
---

 Summary: Concurrency issues in CachingResourceLoader
 Key: TRINIDAD-2463
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2463
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


I am seeing intermittent failures when serving up skin-generated .css files via 
the Trinidad ResourceServlet.  When the failure occurs, the ResourceServlet 
sends a response with conflicting information: the response specifies a 
Content-Length header that does not match the number of bytes of data that are 
sent.  In particular, the Content-Length header specifies the correct size of 
the .css file as it appears on the file system, but the content that is sent 
back to the browser is truncated.

Although I haven’t been able to reproduce the problem in a debugger, I suspect 
that the problem is due to the unsafe way in which 
CachingResourceLoader.URLStreamHandlerImpl deals with withs cached state.

One obvious issue with this code is that it is not thread safe.  It performs 
non-atomic operations (check and set) of the _contents and _contentsModified 
fields without synchronization (or without any other scheme to ensure thread 
safety).  Additionally, there is nothing protecting against these fields being 
modified concurrently.  Also, there is no attempt to ensure that the values 
assigned to these fields are published safely.

This is bad.

Another possible concern is that in theory we could end up reading the .css 
file contents off of the file system while this file is being written to by a 
second thread.  In this case, our cached contents may not reflect the full 
contents of the file as it (eventually) appears on the file system.   However, 
since we always retrieve the value for the Content-Length response header from 
the file system, we always send the latest file size, even if this does not 
match the number of bytes that we have cached.

This could explain the mismatch that I am seeing between the Content-Length 
header and the size of our response payload.

We need to do two things:

1.  Make CachingResourceLoader.URLStreamHandlerImpl thread safe.
2.  Make CachingResourceLoader more tolerant of content length changes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2463) Concurrency issues in CachingResourceLoader

2014-03-25 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2463:

Status: Patch Available (was: Open)

Concurrency issues in CachingResourceLoader
---

Key: TRINIDAD-2463
URL: https://issues.apache.org/jira/browse/TRINIDAD-2463
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
Attachments: trinidad-2463.patch

I am seeing intermittent failures when serving up skin-generated .css files
via the Trinidad ResourceServlet. When the failure occurs, the
ResourceServlet sends a response with conflicting information: the response
specifies a Content-Length header that does not match the number of bytes of
data that are sent. In particular, the Content-Length header specifies the
correct size of the .css file as it appears on the file system, but the
content that is sent back to the browser is truncated.
Although I haven’t been able to reproduce the problem in a debugger, I
suspect that the problem is due to the unsafe way in which
CachingResourceLoader.URLStreamHandlerImpl deals with withs cached state.
One obvious issue with this code is that it is not thread safe. It performs
non-atomic operations (check and set) of the _contents and _contentsModified
fields without synchronization (or without any other scheme to ensure thread
safety). Additionally, there is nothing protecting against these fields
being modified concurrently. Also, there is no attempt to ensure that the
values assigned to these fields are published safely.
This is bad.
Another possible concern is that in theory we could end up reading the .css
file contents off of the file system while this file is being written to by a
second thread. In this case, our cached contents may not reflect the full
contents of the file as it (eventually) appears on the file system.
However, since we always retrieve the value for the Content-Length response
header from the file system, we always send the latest file size, even if
this does not match the number of bytes that we have cached.
This could explain the mismatch that I am seeing between the Content-Length
header and the size of our response payload.
We need to do two things:
1. Make CachingResourceLoader.URLStreamHandlerImpl thread safe.
2. Make CachingResourceLoader more tolerant of content length changes.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TRINIDAD-2463) Concurrency issues in CachingResourceLoader

2014-03-25 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947400#comment-13947400
]

Andy Schwartz commented on TRINIDAD-2463:
-

The attached patch addresses this:

1. Make CachingResourceLoader.URLStreamHandlerImpl thread safe.

By storing URLStreamHandlerImpl's mutable state in a new immutable
CachedContents class that is managed via an AtomicReference.

And this:

2. Make CachingResourceLoader more tolerant of content length changes.

By adding checks for content length vs. cached content size mismatches. In the
event that a mismatch is detected, we a) clear our cached data, which should
allow the cache to recover on subsequent requests and b) send an error back to
the browser, which seems like an improvement over sending the potentially bogus
contents.

Concurrency issues in CachingResourceLoader
---

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2447) UIComponent.isCompositeComponent() is slow for UIXComponents

2014-01-23 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2447:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
   Status: Resolved  (was: Patch Available)

Implemented fix as described above.

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

 Key: TRINIDAD-2447
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2447
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.1-core

 Attachments: trinidad-2447.patch


 The JSF implementations hammer on UIComponent.isCompositeComponent () - eg. 
 this is called for each time the pushComponentToEL()/popComponentFromEL() 
 methods are called, which is all of the time.
 isCompositeComponent() performs the following check:
 component.getAttributes().containsKey(Resource.COMPONENT_RESOURCE_KEY);
 Unfortunately, this operation is slower than it should be for Trinidad-based 
 UIXComponents.  There reason for this is the non-optimal implementation of 
 containsKey in Trinidad's ValueMap:
   public boolean containsKey(Object key)
   {
 if (key == null)
   throw new NullPointerException();
 PropertyKey propertyKey = _getPropertyKey(key);
 
 if (_bean.keySet().contains(propertyKey))
   return true;
 else
   return _bean.bindingKeySet().contains(propertyKey);
   }
 We're creating key sets for both the FacesBean properties and value 
 expressions.  Aside from the overhead of creating these key sets, this also 
 means that we bypass optimizations in FlaggedPropertyMap.
 This is showing up as a hot spot in JProfiler, so would like to see this 
 optimized.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (TRINIDAD-2447) UIComponent.isCompositeComponent() is slow for UIXComponents

2014-01-22 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2447:
---

 Summary: UIComponent.isCompositeComponent() is slow for 
UIXComponents
 Key: TRINIDAD-2447
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2447
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


The JSF implementations hammer on UIComponent.isCompositeComponent () - eg. 
this is called for each time the pushComponentToEL()/popComponentFromEL() 
methods are called, which is all of the time.

isCompositeComponent() performs the following check:

component.getAttributes().containsKey(Resource.COMPONENT_RESOURCE_KEY);

Unfortunately, this operation is slower than it should be for Trinidad-based 
UIXComponents.  There reason for this is the non-optimal implementation of 
containsKey in Trinidad's ValueMap:

  public boolean containsKey(Object key)
  {
if (key == null)
  throw new NullPointerException();

PropertyKey propertyKey = _getPropertyKey(key);

if (_bean.keySet().contains(propertyKey))
  return true;
else
  return _bean.bindingKeySet().contains(propertyKey);
  }

We're creating key sets for both the FacesBean properties and value 
expressions.  Aside from the overhead of creating these key sets, this also 
means that we bypass optimizations in FlaggedPropertyMap.

This is showing up as a hot spot in JProfiler, so would like to see this 
optimized.






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Comment Edited] (TRINIDAD-2447) UIComponent.isCompositeComponent() is slow for UIXComponents

2014-01-22 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878834#comment-13878834
 ] 

Andy Schwartz edited comment on TRINIDAD-2447 at 1/22/14 5:09 PM:
--

The proposed fix does two things:

1.  It optimizes ValueMap.containsKey() to use FacesBean.getRawProperty().
2.  It registers a PropertyKey for Resource.COMPONENT_RESOURCE_KEY.

#1 avoids the unnecessary key set creation.
#2 makes COMPONENT_RESOURCE_KEY an indexed property, thus allowing 
FlaggedPropertyMap to optimize gets.


was (Author: andy.schwartz):
Proposed fix.

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

 Key: TRINIDAD-2447
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2447
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2447.patch


 The JSF implementations hammer on UIComponent.isCompositeComponent () - eg. 
 this is called for each time the pushComponentToEL()/popComponentFromEL() 
 methods are called, which is all of the time.
 isCompositeComponent() performs the following check:
 component.getAttributes().containsKey(Resource.COMPONENT_RESOURCE_KEY);
 Unfortunately, this operation is slower than it should be for Trinidad-based 
 UIXComponents.  There reason for this is the non-optimal implementation of 
 containsKey in Trinidad's ValueMap:
   public boolean containsKey(Object key)
   {
 if (key == null)
   throw new NullPointerException();
 PropertyKey propertyKey = _getPropertyKey(key);
 
 if (_bean.keySet().contains(propertyKey))
   return true;
 else
   return _bean.bindingKeySet().contains(propertyKey);
   }
 We're creating key sets for both the FacesBean properties and value 
 expressions.  Aside from the overhead of creating these key sets, this also 
 means that we bypass optimizations in FlaggedPropertyMap.
 This is showing up as a hot spot in JProfiler, so would like to see this 
 optimized.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (TRINIDAD-2447) UIComponent.isCompositeComponent() is slow for UIXComponents

2014-01-22 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2447:


Status: Patch Available  (was: Open)

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

 Key: TRINIDAD-2447
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2447
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2447.patch


 The JSF implementations hammer on UIComponent.isCompositeComponent () - eg. 
 this is called for each time the pushComponentToEL()/popComponentFromEL() 
 methods are called, which is all of the time.
 isCompositeComponent() performs the following check:
 component.getAttributes().containsKey(Resource.COMPONENT_RESOURCE_KEY);
 Unfortunately, this operation is slower than it should be for Trinidad-based 
 UIXComponents.  There reason for this is the non-optimal implementation of 
 containsKey in Trinidad's ValueMap:
   public boolean containsKey(Object key)
   {
 if (key == null)
   throw new NullPointerException();
 PropertyKey propertyKey = _getPropertyKey(key);
 
 if (_bean.keySet().contains(propertyKey))
   return true;
 else
   return _bean.bindingKeySet().contains(propertyKey);
   }
 We're creating key sets for both the FacesBean properties and value 
 expressions.  Aside from the overhead of creating these key sets, this also 
 means that we bypass optimizations in FlaggedPropertyMap.
 This is showing up as a hot spot in JProfiler, so would like to see this 
 optimized.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (TRINIDAD-2443) Reduce severity of component binding reuse message

2014-01-10 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2443:

Resolution: Fixed
Fix Version/s: 2.1.1-core
Status: Resolved (was: Patch Available)

Reduced the logger level to INFO.

Reduce severity of component binding reuse message
--

Key: TRINIDAD-2443
URL: https://issues.apache.org/jira/browse/TRINIDAD-2443
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
Fix For: 2.1.1-core

Attachments: TRINIDAD-2443-take2.patch, TRINIDAD-2443.patch

As part of our changes for:
TRINIDAD-2409 improve diagnostics during tag execution component binding
failures
We added some logging to UIXComponentELTag.createComponent() when we detect a
newly created component with a stale parent.
The idea behind this logging is that it should help catch cases where the
component tree is being pinned in memory, typically by using a component
binding that references a long-lived (eg. session scope.
However, it turns out that we're detecting (and logging the severe message
for) other cases. For example:
- A page fragment defines a component with a binding that points to a request
scoped bean.
- The page fragment is jsp:included into both page1.jspx and page2.jspx.
- The user navigates from page1.jspx to page2.jspx (with no redirect).
At this point we see the severe message, even though there is no risk of
component tree pinning.
Unfortunately, we don't just see the message once, but repeatedly on every
navigation. And since the message is being logged as severe, it will likely
show up in (and bloat) logs for production deployments.
I think that this message is still useful, but more for debugging purposes
than for production error reporting. As such, opening this issue to request
that we crank the severity down.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (TRINIDAD-2443) Reduce severity of component binding reuse message

2014-01-09 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2443:
---

 Summary: Reduce severity of component binding reuse message
 Key: TRINIDAD-2443
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2443
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


As part of our changes for:

TRINIDAD-2409 improve diagnostics during tag execution component binding 
failures

We added some logging to UIXComponentELTag.createComponent() when we detect a 
newly created component with a stale parent.

The idea behind this logging is that it should help catch cases where the 
component tree is being pinned in memory, typically by  using a component 
binding that references a long-lived (eg. session scope.

However, it turns out that we're detecting (and logging the severe message for) 
other cases.  For example:

- A page fragment defines a component with a binding that points to a request 
scoped bean.
- The page fragment is jsp:included into both page1.jspx and page2.jspx.
- The user navigates from page1.jspx to page2.jspx (with no redirect).

At this point we see the severe message, even though there is no risk of 
component tree pinning.

Unfortunately, we don't just see the message once, but repeatedly on every 
navigation.  And since the message is being logged as severe, it will likely 
show up in (and bloat) logs for production deployments.

I think that this message is still useful, but more for debugging purposes than 
for production error reporting.  As such, opening this issue to request that we 
crank the severity down.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (TRINIDAD-2443) Reduce severity of component binding reuse message

2014-01-09 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2443:

Status: Patch Available (was: Open)

Reduce severity of component binding reuse message
--

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (TRINIDAD-2410) LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND

2013-11-05 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2410:


   Resolution: Fixed
Fix Version/s: 2.1.0-core
   Status: Resolved  (was: Patch Available)

 LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND
 

 Key: TRINIDAD-2410
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2410
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: trinidad-2410.patch


 UIXEditableValue includes the following two property key definitions:
   static public final PropertyKey LOCAL_VALUE_SET_KEY =
 TYPE.registerKey(localValueSet, Boolean.class);
   static public final PropertyKey SUBMITTED_VALUE_KEY =
 TYPE.registerKey(submittedValue);
 Note that although neither of these property keys support EL binding, the 
 property key definitions fail to specify the PropertyKey.CAP_NOT_BOUND 
 capability.
 We should specify this to avoid unnecessary lookups in the ValueExpression 
 map.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (TRINIDAD-2410) LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND

2013-08-26 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2410:
---

 Summary: LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should 
specify CAP_NOT_BOUND
 Key: TRINIDAD-2410
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2410
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


UIXEditableValue includes the following two property key definitions:

  static public final PropertyKey LOCAL_VALUE_SET_KEY =
TYPE.registerKey(localValueSet, Boolean.class);
  static public final PropertyKey SUBMITTED_VALUE_KEY =
TYPE.registerKey(submittedValue);

Note that although neither of these property keys support EL binding, the 
property key definitions fail to specify the PropertyKey.CAP_NOT_BOUND 
capability.

We should specify this to avoid unnecessary lookups in the ValueExpression map.

--
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

[jira] [Updated] (TRINIDAD-2410) LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND

2013-08-26 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2410:


Status: Patch Available  (was: Open)

 LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND
 

 Key: TRINIDAD-2410
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2410
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2410.patch


 UIXEditableValue includes the following two property key definitions:
   static public final PropertyKey LOCAL_VALUE_SET_KEY =
 TYPE.registerKey(localValueSet, Boolean.class);
   static public final PropertyKey SUBMITTED_VALUE_KEY =
 TYPE.registerKey(submittedValue);
 Note that although neither of these property keys support EL binding, the 
 property key definitions fail to specify the PropertyKey.CAP_NOT_BOUND 
 capability.
 We should specify this to avoid unnecessary lookups in the ValueExpression 
 map.

--
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

[jira] [Created] (TRINIDAD-2404) UIXEditableValue property keys missing CAP_NOT_BOUND

2013-07-27 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2404:
---

 Summary: UIXEditableValue property keys missing CAP_NOT_BOUND
 Key: TRINIDAD-2404
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2404
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Priority: Minor


The following property keys in UIXEditableValue:

  static public final PropertyKey LOCAL_VALUE_SET_KEY =
TYPE.registerKey(localValueSet, Boolean.class);
  static public final PropertyKey SUBMITTED_VALUE_KEY =
TYPE.registerKey(submittedValue);

Do not support EL binding and as such should specify the 
PropertyKey.CAP_NOT_BOUND capability.

This will avoid unnecessary attempts to locate a ValueExpression for these 
properties.

--
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

[jira] [Updated] (TRINIDAD-2404) UIXEditableValue property keys missing CAP_NOT_BOUND

2013-07-27 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2404:


Status: Patch Available  (was: Open)

 UIXEditableValue property keys missing CAP_NOT_BOUND
 

 Key: TRINIDAD-2404
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2404
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Andy Schwartz
Priority: Minor
 Attachments: TRINIDAD-2404.patch


 The following property keys in UIXEditableValue:
   static public final PropertyKey LOCAL_VALUE_SET_KEY =
 TYPE.registerKey(localValueSet, Boolean.class);
   static public final PropertyKey SUBMITTED_VALUE_KEY =
 TYPE.registerKey(submittedValue);
 Do not support EL binding and as such should specify the 
 PropertyKey.CAP_NOT_BOUND capability.
 This will avoid unnecessary attempts to locate a ValueExpression for these 
 properties.

--
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

[jira] [Updated] (TRINIDAD-2355) The error message displayed for a large file uploaded is not view locale dependent

2013-03-08 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2355:


   Resolution: Fixed
Fix Version/s: 2.1.0-core
 Assignee: Andy Schwartz
   Status: Resolved  (was: Patch Available)

Commit Anshu's patch in r1454406.

 The error message displayed for a large file uploaded is not view locale 
 dependent
 --

 Key: TRINIDAD-2355
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2355
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.0.1-core, 2.1.0-core
 Environment: The bug occurs across environments.
Reporter: Anshu Jain
Assignee: Andy Schwartz
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2355.patch, TRINIDAD-2355.patch, 
 TRINIDAD-2355_Updated.patch


 When using inputFile component to upload a too large file, the error message 
 The file could not be uploaded because it is too large popups up. But this 
 message is rendered in the default locale set in the server and not in the 
 view/browser locale.
 The message should appear according to the view/browser locale.

--
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

[jira] [Updated] (TRINIDAD-2360) Size of the pop-up window does not honor the width and height parameters provided in IE

2013-02-28 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2360:


   Resolution: Fixed
Fix Version/s: 2.1.0-core
   Status: Resolved  (was: Patch Available)

 Size of the pop-up window does not honor the width and height parameters 
 provided in IE
 ---

 Key: TRINIDAD-2360
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2360
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.0.1-core, 2.1.0-core
 Environment: The issue occurs only in Internet Explorer.
Reporter: Anshu Jain
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2360-code-review.patch, 
 TRINIDAD-2360-code-review-take2.patch, TRINIDAD-2360.patch, 
 TRINIDAD-2360_Updated.patch


 If the width and height of a pop-up window is passed on as parameters, the 
 pop-up on opening is not of the provided size. The width is slightly more and 
 the height is reduced from the provided parameters. This behaviors occurs 
 only in IE. For other browsers like Chrome and Firefox, the popup is of 
 correct size as passed through the parameters.

--
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

[jira] [Commented] (TRINIDAD-2360) Size of the pop-up window does not honor the width and height parameters provided in IE

2013-02-28 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589605#comment-13589605
 ] 

Andy Schwartz commented on TRINIDAD-2360:
-

I committed this version of the fix to trunk:

https://issues.apache.org/jira/secure/attachment/12570150/TRINIDAD-2360-code-review-take2.patch

Thanks for working on this issue Anshu!

 Size of the pop-up window does not honor the width and height parameters 
 provided in IE
 ---

 Key: TRINIDAD-2360
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2360
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.0.1-core, 2.1.0-core
 Environment: The issue occurs only in Internet Explorer.
Reporter: Anshu Jain
Assignee: Andy Schwartz
Priority: Minor
 Attachments: TRINIDAD-2360-code-review.patch, 
 TRINIDAD-2360-code-review-take2.patch, TRINIDAD-2360.patch, 
 TRINIDAD-2360_Updated.patch


 If the width and height of a pop-up window is passed on as parameters, the 
 pop-up on opening is not of the provided size. The width is slightly more and 
 the height is reduced from the provided parameters. This behaviors occurs 
 only in IE. For other browsers like Chrome and Firefox, the popup is of 
 correct size as passed through the parameters.

--
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

[jira] [Created] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily

2013-02-04 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2359:
---

 Summary: ClearRequestExternalContext wrapper applied unnecessarily
 Key: TRINIDAD-2359
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2359
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


GlobalConfiguratorImpl wraps the ExternalContext with a 
ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back in 
Mojarra 1.2.04) is present.

The Mojarra issue is described here:

http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset 
request maps

Two problems with this:

1.  This issue was fixed in 2007, so it is unclear whether we should ever 
bother applying this workaround.
2.  The code which detects the presence of this Mojarra issue is buggy.

As a result of #2, GlobalConfiguratorImpl always adds a 
ClearRequestExternalContext wrapper, regardless of whether the old Mojarra 
issue is present or not.

--
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

[jira] [Commented] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily

2013-02-04 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570626#comment-13570626
 ] 

Andy Schwartz commented on TRINIDAD-2359:
-

More details on #2 above...

GlobalConfiguratorImpl._isSetRequestBugPresent() performs the following test:


  // Call getInitParameterMap() up front
  ec.getInitParameterMap();

  ec.setRequest(new TestRequest(orig));

  _sHasSetRequestBug = !TestRequest.isTestParamPresent(ec);

Where TestRequest looks like this:

  static private class TestRequest
extends ServletRequestWrapper
  {
public TestRequest(ServletRequest request)
{
  super(request);
}

@Override
public String getParameter(String string)
{
  if (_TEST_PARAM.equals(string))
  {
return passed;
  }

  return super.getParameter(string);
}

static public final boolean isTestParamPresent(ExternalContext ec)
{
  return RequestStateMap.getInstance(ec).get(_TEST_PARAM) != null;
}

static private String _TEST_PARAM = TestRequest.class.getName() + 
.TEST_PARAM;
  }

TestRequest.isTestParamPresent() is checking for the presence of this 
_TEST_PARAM in the RequestStateMap.  However, the _TEST_PARAM lives in the 
ServletRequest's parameter map.  As far as I can tell, these are different 
things - ie. the RequestStateMap does not actually delegate through to the 
ServletRequest's parameter map.  Thus isTestParamPresent() will always return 
false, even when the _TEST_PARAM is accessible via the request parameter map. 



 ClearRequestExternalContext wrapper applied unnecessarily
 -

 Key: TRINIDAD-2359
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2359
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor

 GlobalConfiguratorImpl wraps the ExternalContext with a 
 ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back 
 in Mojarra 1.2.04) is present.
 The Mojarra issue is described here:
 http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset 
 request maps
 Two problems with this:
 1.  This issue was fixed in 2007, so it is unclear whether we should ever 
 bother applying this workaround.
 2.  The code which detects the presence of this Mojarra issue is buggy.
 As a result of #2, GlobalConfiguratorImpl always adds a 
 ClearRequestExternalContext wrapper, regardless of whether the old Mojarra 
 issue is present or not.

--
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

[jira] [Commented] (TRINIDAD-2359) ClearRequestExternalContext wrapper applied unnecessarily

2013-02-04 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570630#comment-13570630
]

Andy Schwartz commented on TRINIDAD-2359:
-

This patch:

https://issues.apache.org/jira/secure/attachment/12567885/trinidad-2359.patch

Fixes the isTestParamPresent() present by looking for the test parameter in the
ExternalContext's request parameter map instead of in the RequestStateMap.

I suppose we could rip this code out altogether, though perhaps this test could
be useful for catching future regressions?

ClearRequestExternalContext wrapper applied unnecessarily
-

Key: TRINIDAD-2359
URL: https://issues.apache.org/jira/browse/TRINIDAD-2359
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
Attachments: trinidad-2359.patch

GlobalConfiguratorImpl wraps the ExternalContext with a
ClearRequestExternalContext if it detects that Mojarra issue 493 (fixed back
in Mojarra 1.2.04) is present.
The Mojarra issue is described here:
http://java.net/jira/browse/JAVASERVERFACES-493 setRequest does not reset
request maps
Two problems with this:
1. This issue was fixed in 2007, so it is unclear whether we should ever
bother applying this workaround.
2. The code which detects the presence of this Mojarra issue is buggy.
As a result of #2, GlobalConfiguratorImpl always adds a
ClearRequestExternalContext wrapper, regardless of whether the old Mojarra
issue is present or not.

--
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

[jira] [Updated] (TRINIDAD-2344) Maven-faces-plugin faces-config.xml generation support for pass through component types

2012-11-29 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2344:


Status: Patch Available  (was: Open)

 Maven-faces-plugin faces-config.xml generation support for pass through 
 component types
 ---

 Key: TRINIDAD-2344
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2344
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2344.patch


 Trinidad's GenerateFacesConfigMojo filters out any faces-config.xml component 
 entries that do not match the typePrefix parameter.  This can be annoying, 
 since in some cases it may be necessary to override component implementations 
 for component types that are outside of the normal typePrefix.
 We addressed this in a one-off fashion here:
 TRINIDAD-1656 Maven-faces-plugin faces-config.xml generation does not allow 
 ViewRoot replacement
 But this solution is too constrained, as it only allows the 
 javax.faces.ViewRoot component type to be replaced.
 Logging this issue to request that we add some more generic solution.

--
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

[jira] [Created] (TRINIDAD-2345) Clean up maven-faces-plugin transform xsl duplication

2012-11-29 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2345:
---

 Summary: Clean up maven-faces-plugin transform xsl duplication
 Key: TRINIDAD-2345
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2345
 Project: MyFaces Trinidad
  Issue Type: Task
  Components: Build
Reporter: Andy Schwartz
Priority: Minor


The trinidad-maven/maven-faces-plugin uses the following XSLT style sheets to 
manipulate a base faces-config.xml document:

./maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform20.xsl
./maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform.xsl
./maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform21.xsl
./maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform12.xsl

There is an unreasonable amount of duplication across these files, which makes 
any sort of maintenance way more difficult than necessary.

Logging this issue to track the fact that we need to clean this up.

--
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

[jira] [Commented] (TRINIDAD-2343) Hook for overriding UIXCollection temp var storage

2012-11-29 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506740#comment-13506740
 ] 

Andy Schwartz commented on TRINIDAD-2343:
-

Committed fix to trunk in r1415347.

 Hook for overriding UIXCollection temp var storage
 --

 Key: TRINIDAD-2343
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2343
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: trinidad-2343.patch


 UIXCollection uses the following private method for storing temporary 
 variables (eg. var and varStatus values):
   private Object _setELVar(String varName, Object newData)
   {
 if (varName == null)
   return null;
 // we need to place each row at an EL reachable place so that it
 // can be accessed via the 'var' variable. Let's place it on the
 // requestMap:
 return TableUtils.setupELVariable(getFacesContext(), varName, newData);
   }
 I need to override this behavior in my subclasses of UIXCollection as I have 
 my own mechanism for managing temporary variables.
 Logging this issue to request that we expose a protected hook that subclasses 
 can override to provide alternate implementations of temporary variable 
 storage.

--
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

[jira] [Updated] (TRINIDAD-2343) Hook for overriding UIXCollection temp var storage

2012-11-29 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2343:


   Resolution: Fixed
Fix Version/s: 2.1.0-core
   Status: Resolved  (was: Patch Available)

 Hook for overriding UIXCollection temp var storage
 --

 Key: TRINIDAD-2343
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2343
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: trinidad-2343.patch


 UIXCollection uses the following private method for storing temporary 
 variables (eg. var and varStatus values):
   private Object _setELVar(String varName, Object newData)
   {
 if (varName == null)
   return null;
 // we need to place each row at an EL reachable place so that it
 // can be accessed via the 'var' variable. Let's place it on the
 // requestMap:
 return TableUtils.setupELVariable(getFacesContext(), varName, newData);
   }
 I need to override this behavior in my subclasses of UIXCollection as I have 
 my own mechanism for managing temporary variables.
 Logging this issue to request that we expose a protected hook that subclasses 
 can override to provide alternate implementations of temporary variable 
 storage.

--
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

[jira] [Created] (TRINIDAD-2343) Hook for overriding UIXCollection temp var storage

2012-11-27 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2343:
---

 Summary: Hook for overriding UIXCollection temp var storage
 Key: TRINIDAD-2343
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2343
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


UIXCollection uses the following private method for storing temporary variables 
(eg. var and varStatus values):

  private Object _setELVar(String varName, Object newData)
  {
if (varName == null)
  return null;

// we need to place each row at an EL reachable place so that it
// can be accessed via the 'var' variable. Let's place it on the
// requestMap:
return TableUtils.setupELVariable(getFacesContext(), varName, newData);
  }

I need to override this behavior in my subclasses of UIXCollection as I have my 
own mechanism for managing temporary variables.

Logging this issue to request that we expose a protected hook that subclasses 
can override to provide alternate implementations of temporary variable storage.

--
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

[jira] [Comment Edited] (TRINIDAD-2343) Hook for overriding UIXCollection temp var storage

2012-11-27 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504672#comment-13504672
 ] 

Andy Schwartz edited comment on TRINIDAD-2343 at 11/27/12 3:23 PM:
---

The attached patch replaces the private _setTempVar() method with the following 
protected API:


  /**
   * Called by UIXCollection to set values for the var and
   * varStatus EL variables.
   *
   * @param context the FacesContext for the current request
   * @param name the non-null name of the EL variable
   * @param value the value of the EL variable
   * @return the previous value of the EL variable, or null if
   * the value was not previously set.
   */
  protected Object setupELVariable(
FacesContext context,
String   name,
Object   value
)


  was (Author: andy.schwartz):
Proposed fix.
  
 Hook for overriding UIXCollection temp var storage
 --

 Key: TRINIDAD-2343
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2343
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2343.patch


 UIXCollection uses the following private method for storing temporary 
 variables (eg. var and varStatus values):
   private Object _setELVar(String varName, Object newData)
   {
 if (varName == null)
   return null;
 // we need to place each row at an EL reachable place so that it
 // can be accessed via the 'var' variable. Let's place it on the
 // requestMap:
 return TableUtils.setupELVariable(getFacesContext(), varName, newData);
   }
 I need to override this behavior in my subclasses of UIXCollection as I have 
 my own mechanism for managing temporary variables.
 Logging this issue to request that we expose a protected hook that subclasses 
 can override to provide alternate implementations of temporary variable 
 storage.

--
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

[jira] [Created] (TRINIDAD-2344) Maven-faces-plugin faces-config.xml generation support for pass through component types

2012-11-27 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2344:
---

 Summary: Maven-faces-plugin faces-config.xml generation support 
for pass through component types
 Key: TRINIDAD-2344
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2344
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


Trinidad's GenerateFacesConfigMojo filters out any faces-config.xml component 
entries that do not match the typePrefix parameter.  This can be annoying, 
since in some cases it may be necessary to override component implementations 
for component types that are outside of the normal typePrefix.

We addressed this in a one-off fashion here:

TRINIDAD-1656 Maven-faces-plugin faces-config.xml generation does not allow 
ViewRoot replacement

But this solution is too constrained, as it only allows the 
javax.faces.ViewRoot component type to be replaced.

Logging this issue to request that we add some more generic solution.

--
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

[jira] [Updated] (TRINIDAD-2343) Hook for overriding UIXCollection temp var storage

2012-11-27 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2343:


Status: Patch Available  (was: Open)

 Hook for overriding UIXCollection temp var storage
 --

 Key: TRINIDAD-2343
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2343
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2343.patch


 UIXCollection uses the following private method for storing temporary 
 variables (eg. var and varStatus values):
   private Object _setELVar(String varName, Object newData)
   {
 if (varName == null)
   return null;
 // we need to place each row at an EL reachable place so that it
 // can be accessed via the 'var' variable. Let's place it on the
 // requestMap:
 return TableUtils.setupELVariable(getFacesContext(), varName, newData);
   }
 I need to override this behavior in my subclasses of UIXCollection as I have 
 my own mechanism for managing temporary variables.
 Logging this issue to request that we expose a protected hook that subclasses 
 can override to provide alternate implementations of temporary variable 
 storage.

--
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

[jira] [Commented] (TRINIDAD-2340) LocaleElementsResourceLoader init dependency on request path

2012-11-21 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502151#comment-13502151
 ] 

Andy Schwartz commented on TRINIDAD-2340:
-

Committed the following fix to trunk:

http://svn.apache.org/viewvc?view=revisionrevision=1412206

 LocaleElementsResourceLoader init dependency on request path
 

 Key: TRINIDAD-2340
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
 Fix For: 2.0.2-core

 Attachments: trinidad-2340.patch


 The LocaleElementsResourceLoader static initializer attempts to derive a 
 locale elements library uri:
   static private final ResourceLoader[] _ResourceLoaders =
   {
 new ClassLoaderResourceLoader(),
 new 
 TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI(Translations,
  false))
   };
  
 The call to getLocaleElementsURI() ends up calling 
 CoreRenderKitResourceLoader.getLocale(), which in turn does the following:
   static public String getLocale()
   {
 String path = ((HttpServletRequest) 
 FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo();
 String locStr = ;
 int locIndex = path.indexOf(LocaleElements)+ LocaleElements_.length();
 int index = path.indexOf(_VERSION);
 if (index  0)
   index = path.indexOf(.js);
 if(index = 0)
   locStr = path.substring(locIndex, index);
 return locStr;
   }
 Note that this code assumes that the request path returned from getPathInfo() 
 corresponds to a LocaleElements library request.  While this true during 
 normal resource request processing (ie. when ResourceLoader.getResource() is 
 called), this is not necessarily true when called from the 
 LocaleElementsResourceLoader static initializer.
 Depending on when the LocaleElementsResourceLoader is initialized, a call to 
 getLocale() can result in:
 1.  A NullPointerException, if the FacesContext is not available, or if 
 getRequest() happens to return null.
 2.  A StringIndexOutOfBoundsException from the substring() call, if the 
 request path happens to be short.
 3.  A garbage return value, if one of the above two exceptions are not thrown.
 As such, it is not safe for LocaleElementsResourceLoader to call into 
 getLocaleElementsURI() from its static initializer.
 Although this seems like a trivial issue, I specified the priority as major 
 as we are seeing #2 in production environments.

--
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

[jira] [Updated] (TRINIDAD-2340) LocaleElementsResourceLoader init dependency on request path

2012-11-21 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2340:


   Resolution: Fixed
Fix Version/s: 2.0.2-core
   Status: Resolved  (was: Patch Available)

Avoid calling CoreRenderKitResourceLoader.getLocaleElementsURI() during 
resource loader initialization, as it is not safe to depend on the request uri 
at this time.  Fortunately, this call was entirely unnecessary, so we can 
simply remove it with no negative impact.

Added a small unit test that verifies that the CoreRenderKitResourceLoader (and 
thus the LocaleElementsResourceLoader) can be instantiated without access to a 
FacesContext (and thus is not dependent on any request-specific state).

 LocaleElementsResourceLoader init dependency on request path
 

 Key: TRINIDAD-2340
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
 Fix For: 2.0.2-core

 Attachments: trinidad-2340.patch


 The LocaleElementsResourceLoader static initializer attempts to derive a 
 locale elements library uri:
   static private final ResourceLoader[] _ResourceLoaders =
   {
 new ClassLoaderResourceLoader(),
 new 
 TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI(Translations,
  false))
   };
  
 The call to getLocaleElementsURI() ends up calling 
 CoreRenderKitResourceLoader.getLocale(), which in turn does the following:
   static public String getLocale()
   {
 String path = ((HttpServletRequest) 
 FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo();
 String locStr = ;
 int locIndex = path.indexOf(LocaleElements)+ LocaleElements_.length();
 int index = path.indexOf(_VERSION);
 if (index  0)
   index = path.indexOf(.js);
 if(index = 0)
   locStr = path.substring(locIndex, index);
 return locStr;
   }
 Note that this code assumes that the request path returned from getPathInfo() 
 corresponds to a LocaleElements library request.  While this true during 
 normal resource request processing (ie. when ResourceLoader.getResource() is 
 called), this is not necessarily true when called from the 
 LocaleElementsResourceLoader static initializer.
 Depending on when the LocaleElementsResourceLoader is initialized, a call to 
 getLocale() can result in:
 1.  A NullPointerException, if the FacesContext is not available, or if 
 getRequest() happens to return null.
 2.  A StringIndexOutOfBoundsException from the substring() call, if the 
 request path happens to be short.
 3.  A garbage return value, if one of the above two exceptions are not thrown.
 As such, it is not safe for LocaleElementsResourceLoader to call into 
 getLocaleElementsURI() from its static initializer.
 Although this seems like a trivial issue, I specified the priority as major 
 as we are seeing #2 in production environments.

--
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

[jira] [Created] (TRINIDAD-2340) LocaleElementsResourceLoader init dependency on request path

2012-11-20 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2340:
---

 Summary: LocaleElementsResourceLoader init dependency on request 
path
 Key: TRINIDAD-2340
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz


The LocaleElementsResourceLoader static initializer attempts to derive a locale 
elements library uri:

  static private final ResourceLoader[] _ResourceLoaders =
  {
new ClassLoaderResourceLoader(),
new 
TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI(Translations,
 false))
  };
 
The call to getLocaleElementsURI() ends up calling 
CoreRenderKitResourceLoader.getLocale(), which in turn does the following:

  static public String getLocale()
  {
String path = ((HttpServletRequest) 
FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo();
String locStr = ;

int locIndex = path.indexOf(LocaleElements)+ LocaleElements_.length();
int index = path.indexOf(_VERSION);

if (index  0)
  index = path.indexOf(.js);

if(index = 0)
  locStr = path.substring(locIndex, index);

return locStr;
  }

Note that this code assumes that the request path returned from getPathInfo() 
corresponds to a LocaleElements library request.  While this true during normal 
resource request processing (ie. when ResourceLoader.getResource() is called), 
this is not necessarily true when called from the LocaleElementsResourceLoader 
static initializer.

Depending on when the LocaleElementsResourceLoader is initialized, a call to 
getLocale() can result in:

1.  A NullPointerException, if the FacesContext is not available, or if 
getRequest() happens to return null.
2.  A StringIndexOutOfBoundsException from the substring() call, if the request 
path happens to be short.
3.  A garbage return value, if one of the above two exceptions are not thrown.

As such, it is not safe for LocaleElementsResourceLoader to call into 
getLocaleElementsURI() from its static initializer.

Although this seems like a trivial issue, I specified the priority as major 
as we are seeing #2 in production environments.

--
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

[jira] [Commented] (TRINIDAD-2340) LocaleElementsResourceLoader init dependency on request path

2012-11-20 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501415#comment-13501415
 ] 

Andy Schwartz commented on TRINIDAD-2340:
-

The attached patch:

https://issues.apache.org/jira/secure/attachment/12554395/trinidad-2340.patch

Fixes the issue by removing the unnecessary call to getLocaleElementsURI().

It also adds a test case that verifies that the CoreRenderKitResourceLoader 
(and thus the LocaleElementsResourceLoader) can be constructed without access 
to a FacesContext.

 LocaleElementsResourceLoader init dependency on request path
 

 Key: TRINIDAD-2340
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
 Attachments: trinidad-2340.patch


 The LocaleElementsResourceLoader static initializer attempts to derive a 
 locale elements library uri:
   static private final ResourceLoader[] _ResourceLoaders =
   {
 new ClassLoaderResourceLoader(),
 new 
 TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI(Translations,
  false))
   };
  
 The call to getLocaleElementsURI() ends up calling 
 CoreRenderKitResourceLoader.getLocale(), which in turn does the following:
   static public String getLocale()
   {
 String path = ((HttpServletRequest) 
 FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo();
 String locStr = ;
 int locIndex = path.indexOf(LocaleElements)+ LocaleElements_.length();
 int index = path.indexOf(_VERSION);
 if (index  0)
   index = path.indexOf(.js);
 if(index = 0)
   locStr = path.substring(locIndex, index);
 return locStr;
   }
 Note that this code assumes that the request path returned from getPathInfo() 
 corresponds to a LocaleElements library request.  While this true during 
 normal resource request processing (ie. when ResourceLoader.getResource() is 
 called), this is not necessarily true when called from the 
 LocaleElementsResourceLoader static initializer.
 Depending on when the LocaleElementsResourceLoader is initialized, a call to 
 getLocale() can result in:
 1.  A NullPointerException, if the FacesContext is not available, or if 
 getRequest() happens to return null.
 2.  A StringIndexOutOfBoundsException from the substring() call, if the 
 request path happens to be short.
 3.  A garbage return value, if one of the above two exceptions are not thrown.
 As such, it is not safe for LocaleElementsResourceLoader to call into 
 getLocaleElementsURI() from its static initializer.
 Although this seems like a trivial issue, I specified the priority as major 
 as we are seeing #2 in production environments.

--
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

[jira] [Updated] (TRINIDAD-2340) LocaleElementsResourceLoader init dependency on request path

2012-11-20 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2340:


Status: Patch Available  (was: Open)

 LocaleElementsResourceLoader init dependency on request path
 

 Key: TRINIDAD-2340
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2340
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.0.1-core
Reporter: Andy Schwartz
Assignee: Andy Schwartz
 Attachments: trinidad-2340.patch


 The LocaleElementsResourceLoader static initializer attempts to derive a 
 locale elements library uri:
   static private final ResourceLoader[] _ResourceLoaders =
   {
 new ClassLoaderResourceLoader(),
 new 
 TrTranslationsResourceLoader(CoreRenderKitResourceLoader.getLocaleElementsURI(Translations,
  false))
   };
  
 The call to getLocaleElementsURI() ends up calling 
 CoreRenderKitResourceLoader.getLocale(), which in turn does the following:
   static public String getLocale()
   {
 String path = ((HttpServletRequest) 
 FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPathInfo();
 String locStr = ;
 int locIndex = path.indexOf(LocaleElements)+ LocaleElements_.length();
 int index = path.indexOf(_VERSION);
 if (index  0)
   index = path.indexOf(.js);
 if(index = 0)
   locStr = path.substring(locIndex, index);
 return locStr;
   }
 Note that this code assumes that the request path returned from getPathInfo() 
 corresponds to a LocaleElements library request.  While this true during 
 normal resource request processing (ie. when ResourceLoader.getResource() is 
 called), this is not necessarily true when called from the 
 LocaleElementsResourceLoader static initializer.
 Depending on when the LocaleElementsResourceLoader is initialized, a call to 
 getLocale() can result in:
 1.  A NullPointerException, if the FacesContext is not available, or if 
 getRequest() happens to return null.
 2.  A StringIndexOutOfBoundsException from the substring() call, if the 
 request path happens to be short.
 3.  A garbage return value, if one of the above two exceptions are not thrown.
 As such, it is not safe for LocaleElementsResourceLoader to call into 
 getLocaleElementsURI() from its static initializer.
 Although this seems like a trivial issue, I specified the priority as major 
 as we are seeing #2 in production environments.

--
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

[jira] [Updated] (TRINIDAD-2130) Skinning: support separate style sheets for secure + non-secure pages

2011-09-23 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2130:

Resolution: Fixed
Fix Version/s: 2.0.2-core
Status: Resolved (was: Patch Available)

We now generate separate style sheets for secure/non-secure pages.

Skinning: support separate style sheets for secure + non-secure pages
-

Key: TRINIDAD-2130
URL: https://issues.apache.org/jira/browse/TRINIDAD-2130
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Reporter: Andy Schwartz
Priority: Minor
Fix For: 2.0.2-core

Attachments: trinidad-2130.patch

I have an ExternalContext wrapper that modifies urls that are passed to
ExternalContext.encodeResourceURL(). This includes urls for images
referenced by Trinidad skin definitions.
One possible modification involves converting relative URLs to absolute URLs
(eg. prepending a CDN prefix), including the protocol/host/port.
A problem with this is that we share a single generated style sheet across
http and https pages. This means that if I generate absolute uris with the
http: protocol, these uris will be written into a generated .css file that
would be shared by secure/https pages, in which case the browser may warn
about mixed secure/non-secure content.
I would like to avoid this issue by enhancing Trinidad skinning to support
generation of separate style sheets for secure and non-secure pages. That
way, my ExternalContext wrapper could produce absolute uris with the
appropriate protocol for the current request and avoid mixing
secure/non-secure content.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2130) Skinning: support separate style sheets for secure + non-secure pages

2011-09-22 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2130:

Status: Patch Available (was: Open)

Skinning: support separate style sheets for secure + non-secure pages
-

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2130) Skinning: support separate style sheets for secure + non-secure pages

2011-08-17 Thread Andy Schwartz (JIRA)

Skinning: support separate style sheets for secure + non-secure pages
-

 Key: TRINIDAD-2130
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2130
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Reporter: Andy Schwartz
Priority: Minor


I have an ExternalContext wrapper that modifies urls that are passed to 
ExternalContext.encodeResourceURL().  This includes urls for images referenced 
by Trinidad skin definitions.

One possible modification involves converting relative URLs to absolute URLs 
(eg. prepending a CDN prefix), including the protocol/host/port.

A problem with this is that we share a single generated style sheet across http 
and https pages.  This means that if I generate absolute uris with the http: 
protocol, these uris will be written into a generated .css file that would be 
shared by secure/https pages, in which case the browser may warn about mixed 
secure/non-secure content.

I would like to avoid this issue by enhancing Trinidad skinning to support 
generation of separate style sheets for secure and non-secure pages.  That way, 
my ExternalContext wrapper could produce absolute uris with the appropriate 
protocol for the current request and avoid mixing secure/non-secure content.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TRINIDAD-2129) Component showcase demo broken

2011-08-16 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085873#comment-13085873
 ] 

Andy Schwartz commented on TRINIDAD-2129:
-

This works (somewhat) better when running in Jetty against MyFaces.  The 
panelAccordion is functional, though on every other click I see a component 
with duplicate id foo found error (IllegalStateException). 

 Component showcase demo broken
 --

 Key: TRINIDAD-2129
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2129
 Project: MyFaces Trinidad
  Issue Type: Bug
 Environment: Tested on GlassFish v3.1, though not sure that is 
 significant.  Repros in various browsers (FF, Safari, Chrome).
Reporter: Andy Schwartz

 The Browse Components accordion in the component showcase demo is not 
 working.  It is not possible to disclose any accordion pane.
 Interestingly, the standalone panelAccordion demo under the trinidad-demo 
 example does work without problem.
 Specifying priority as major (and possibly should be higher) as it is 
 possible that this is a symptom of a more fundamental problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components

2011-04-13 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz resolved TRINIDAD-2078.
-

Resolution: Fixed
Fix Version/s: 2.0.0-beta-3

SKIP_ITERATION forces visit of non-rendered components
--

Key: TRINIDAD-2078
URL: https://issues.apache.org/jira/browse/TRINIDAD-2078
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Blake Sullivan
Fix For: 2.0.0-beta-3

Attachments: trin2078_trin2.diff, trinidad-2078.diff

Certain tree visits, such as the PostRestoreStateEvent delivery visit, must
avoid iteration in stamping components (eg. UIData). Before the fix for:
TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property
This was handled in UIXComponent.visitChildren() by checking for the restore
view phase.
As of the fix for 2030, instead of checking the phase id we now check for the
SKIP_ITERATION pseudo-hint.
While this works correctly for the PostRestoreStateEvent visit, it fails in
other cases. The problem: UIXComponent.visitChildren() falls back on a
facets and children traversal when SKIP_ITERATION is set, which means that
we will visit all children (both rendered and non-rendered) even when the
SKIP_UNRENDERED hint is set.
Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly
supported with our current solution. Since this is a valid combination of
hints, we'll need an approach that correctly supports this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2081) UIXShowOne SKIP_UNRENDERED implementation does not match renderer logic

2011-04-05 Thread Andy Schwartz (JIRA)

UIXShowOne SKIP_UNRENDERED implementation does not match renderer logic
---

 Key: TRINIDAD-2081
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2081
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz


UIXShowOne.visitTree() attempts to provide SKIP_UNRENDERED support by only 
visiting the disclosed showDetail child.  However, the current implementation 
is insufficient.  There are two problems:

1.  UIXShowOne.visitTree() does not handle the case where no showDetail child 
is explicitly disclosed.  In this case, the renderer typically forces the first 
rendered/enabled showDetail child to be disclosed.  UIXShowOne.visitTree() has 
no such fallback logic, and thus does not visit any child even though some 
child will be rendered.

2.  More generally, UIXShowOne.visitTree() does not match renderer logic for 
determining which child will be rendered.  For example, UIXShowOne.visitTree() 
only looks at the disclosed attribute.  On the other hand, PanelTabbedRenderer 
checks the rendered and disabled attributes in addition to the disclosed 
attributes.  (Other renderers may check other attributes.)

We need some way to ensure that UIXShowOne's SKIP_UNRENDERED implementation and 
any associated renderers use the same logic to determine which child is in fact 
rendered.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components

2011-04-04 Thread Andy Schwartz (JIRA)

SKIP_ITERATION forces visit of non-rendered components
--

 Key: TRINIDAD-2078
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2078
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz


Certain tree visits, such as the PostRestoreStateEvent delivery visit, must 
avoid iteration in stamping components (eg. UIData).  Before the fix for:

TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property

This was handled in UIXComponent.visitChildren() by checking for the restore 
view phase.

As of the fix for 2030, instead of checking the phase id we now check for the 
SKIP_ITERATION pseudo-hint.

While this works correctly for the PostRestoreStateEvent visit, it fails in 
other cases.  The problem: UIXComponent.visitChildren() falls back on a facets 
and children traversal when SKIP_ITERATION is set, which means that we will 
visit all children (both rendered and non-rendered) even when the 
SKIP_UNRENDERED hint is set.

Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly 
supported with our current solution.  Since this is a valid combination of 
hints, we'll need an approach that correctly supports this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005675#comment-13005675
 ] 

Andy Schwartz commented on TRINIDAD-2056:
-

Commited fix to trunk:

http://svn.apache.org/viewvc?view=revisionrevision=1080600

 Add utility method for locating nearest non-flattening ancestor component
 -

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2056.patch


 In some cases it may be necessary to walk up the ancestor chain to locate the 
 nearest non-flattening parent.  For example, a column component that wants to 
 locate the containing table component would need to skip over any flattening 
 components in between.  Opening this issue to request that we provide a 
 utility method for this instead of requiring each case where this is needed 
 to re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005677#comment-13005677
 ] 

Andy Schwartz commented on TRINIDAD-2055:
-

Committed fix to trunk:

http://svn.apache.org/viewvc?view=revisionrevision=1080604

 Introduce ChangeManager wrapper class
 -

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: ChangeManagerWrapper.java


 One way that users might customize change management behavior is to create a 
 proxy ChangeManager that delegates through to an underlying ChangeManager 
 (eg. to SessionChangeManager) for most operations after performing filtering 
 of the incoming changes.  It is possible to implement such proxy 
 ChangeManager classes today.  However, without a wrapper base class, these 
 implementations are fragile - ie. they will break if we ever introduce a new 
 method to the ChangeManager API.
 A more robust solution would be to introduce a base wrapper class for proxy 
 ChangeManager implementations to extend.  That way, in the event that we do 
 introduce new ChangeManager methods, the base wrapper class can be updated in 
 parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-11 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2056:


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
   Status: Resolved  (was: Patch Available)

 Add utility method for locating nearest non-flattening ancestor component
 -

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: trinidad-2056.patch


 In some cases it may be necessary to walk up the ancestor chain to locate the 
 nearest non-flattening parent.  For example, a column component that wants to 
 locate the containing table component would need to skip over any flattening 
 components in between.  Opening this issue to request that we provide a 
 utility method for this instead of requiring each case where this is needed 
 to re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-11 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2055:


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
   Status: Resolved  (was: Patch Available)

 Introduce ChangeManager wrapper class
 -

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: ChangeManagerWrapper.java


 One way that users might customize change management behavior is to create a 
 proxy ChangeManager that delegates through to an underlying ChangeManager 
 (eg. to SessionChangeManager) for most operations after performing filtering 
 of the incoming changes.  It is possible to implement such proxy 
 ChangeManager classes today.  However, without a wrapper base class, these 
 implementations are fragile - ie. they will break if we ever introduce a new 
 method to the ChangeManager API.
 A more robust solution would be to introduce a base wrapper class for proxy 
 ChangeManager implementations to extend.  That way, in the event that we do 
 introduce new ChangeManager methods, the base wrapper class can be updated in 
 parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005683#comment-13005683
 ] 

Andy Schwartz commented on TRINIDAD-2056:
-

Committed to 1.2.12.5:

http://svn.apache.org/viewvc?view=revisionrevision=1080617

 Add utility method for locating nearest non-flattening ancestor component
 -

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: trinidad-2056.patch


 In some cases it may be necessary to walk up the ancestor chain to locate the 
 nearest non-flattening parent.  For example, a column component that wants to 
 locate the containing table component would need to skip over any flattening 
 components in between.  Opening this issue to request that we provide a 
 utility method for this instead of requiring each case where this is needed 
 to re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005684#comment-13005684
 ] 

Andy Schwartz commented on TRINIDAD-2055:
-

Committed to 1.2.12.5:

http://svn.apache.org/viewvc?view=revisionrevision=1080622

 Introduce ChangeManager wrapper class
 -

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: ChangeManagerWrapper.java


 One way that users might customize change management behavior is to create a 
 proxy ChangeManager that delegates through to an underlying ChangeManager 
 (eg. to SessionChangeManager) for most operations after performing filtering 
 of the incoming changes.  It is possible to implement such proxy 
 ChangeManager classes today.  However, without a wrapper base class, these 
 implementations are fragile - ie. they will break if we ever introduce a new 
 method to the ChangeManager API.
 A more robust solution would be to introduce a base wrapper class for proxy 
 ChangeManager implementations to extend.  That way, in the event that we do 
 introduce new ChangeManager methods, the base wrapper class can be updated in 
 parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005691#comment-13005691
 ] 

Andy Schwartz commented on TRINIDAD-2056:
-

Committed to 1.2.x:

http://svn.apache.org/viewvc?view=revisionrevision=1080628

 Add utility method for locating nearest non-flattening ancestor component
 -

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: trinidad-2056.patch


 In some cases it may be necessary to walk up the ancestor chain to locate the 
 nearest non-flattening parent.  For example, a column component that wants to 
 locate the containing table component would need to skip over any flattening 
 components in between.  Opening this issue to request that we provide a 
 utility method for this instead of requiring each case where this is needed 
 to re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-11 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005692#comment-13005692
 ] 

Andy Schwartz commented on TRINIDAD-2055:
-

Committed to 1.2.x:

http://svn.apache.org/viewvc?view=revisionrevision=1080631

 Introduce ChangeManager wrapper class
 -

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-3

 Attachments: ChangeManagerWrapper.java


 One way that users might customize change management behavior is to create a 
 proxy ChangeManager that delegates through to an underlying ChangeManager 
 (eg. to SessionChangeManager) for most operations after performing filtering 
 of the incoming changes.  It is possible to implement such proxy 
 ChangeManager classes today.  However, without a wrapper base class, these 
 implementations are fragile - ie. they will break if we ever introduce a new 
 method to the ChangeManager API.
 A more robust solution would be to introduce a base wrapper class for proxy 
 ChangeManager implementations to extend.  That way, in the event that we do 
 introduce new ChangeManager methods, the base wrapper class can be updated in 
 parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-10 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2056:


Status: Patch Available  (was: Open)

 Add utility method for locating nearest non-flattening ancestor component
 -

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: trinidad-2056.patch


 In some cases it may be necessary to walk up the ancestor chain to locate the 
 nearest non-flattening parent.  For example, a column component that wants to 
 locate the containing table component would need to skip over any flattening 
 components in between.  Opening this issue to request that we provide a 
 utility method for this instead of requiring each case where this is needed 
 to re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-09 Thread Andy Schwartz (JIRA)

Introduce ChangeManager wrapper class
-

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


One way that users might customize change management behavior is to create a 
proxy ChangeManager that delegates through to an underlying ChangeManager (eg. 
to SessionChangeManager) for most operations after performing filtering of the 
incoming changes.  It is possible to implement such proxy ChangeManager classes 
today.  However, without a wrapper base class, these implementations are 
fragile - ie. they will break if we ever introduce a new method to the 
ChangeManager API.

A more robust solution would be to introduce a base wrapper class for proxy 
ChangeManager implementations to extend.  That way, in the event that we do 
introduce new ChangeManager methods, the base wrapper class can be updated in 
parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TRINIDAD-2056) Add utility method for locating nearest non-flattening ancestor component

2011-03-09 Thread Andy Schwartz (JIRA)

Add utility method for locating nearest non-flattening ancestor component
-

 Key: TRINIDAD-2056
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2056
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor


In some cases it may be necessary to walk up the ancestor chain to locate the 
nearest non-flattening parent.  For example, a column component that wants to 
locate the containing table component would need to skip over any flattening 
components in between.  Opening this issue to request that we provide a utility 
method for this instead of requiring each case where this is needed to 
re-implement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2055) Introduce ChangeManager wrapper class

2011-03-09 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2055:


Status: Patch Available  (was: Open)

 Introduce ChangeManager wrapper class
 -

 Key: TRINIDAD-2055
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2055
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Andy Schwartz
Assignee: Andy Schwartz
Priority: Minor
 Attachments: ChangeManagerWrapper.java


 One way that users might customize change management behavior is to create a 
 proxy ChangeManager that delegates through to an underlying ChangeManager 
 (eg. to SessionChangeManager) for most operations after performing filtering 
 of the incoming changes.  It is possible to implement such proxy 
 ChangeManager classes today.  However, without a wrapper base class, these 
 implementations are fragile - ie. they will break if we ever introduce a new 
 method to the ChangeManager API.
 A more robust solution would be to introduce a base wrapper class for proxy 
 ChangeManager implementations to extend.  That way, in the event that we do 
 introduce new ChangeManager methods, the base wrapper class can be updated in 
 parallel, protecting subclasses from the change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2030) Honor SKIP_ITERATION FacesContext property

2011-03-02 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001437#comment-13001437
 ] 

Andy Schwartz commented on TRINIDAD-2030:
-

Fix committed:

http://svn.apache.org/viewvc?view=revisionrevision=1070523

 Honor SKIP_ITERATION FacesContext property
 --

 Key: TRINIDAD-2030
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2030
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andy Schwartz
Priority: Minor
 Attachments: trinidad-skip-iteration.patch


 As discussed in this MyFaces core issue:
 MYFACES-3036 Support SKIP_ITERATION FacesContext property
 The JSF-314 EG (and members of Mojarra and MyFaces) agreed to use the 
 javax.faces.visit.SKIP_ITERATION FacesContext property (during the 2.0 
 timeframe) to indicate that a tree visit should not trigger iteration in 
 iterating components like UIData/UIRepeat.  Opening this issue to request 
 that iterating Trinidad components (UIXIterator, UIXCollection) honor this 
 property as well.
 Note that Trinidad already handles this centrally in 
 UIXComponent.visitChildren:
   // determine whether this visit should be iterating.  If it shouldn't, 
 don't
   // even call the protected hook.  We currently don't iterate during the
   // restore view phase when we are visiting all of the components.
   boolean noIterate = (visitContext.getIdsToVisit() == 
 VisitContext.ALL_IDS) 
   (context.getCurrentPhaseId() == 
 PhaseId.RESTORE_VIEW);
   doneVisiting =  (noIterate)
 ? uixParentComponent._visitAllChildren(visitContext, 
 callback)
 : uixParentComponent.visitChildren(visitContext, 
 callback);
 This issue is requesting that we enhance the above noIterate test to also 
 check the SKIP_ITERATION property.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2030) Honor SKIP_ITERATION FacesContext property

2011-03-02 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2030:


   Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
   Status: Resolved  (was: Patch Available)

http://svn.apache.org/viewvc?view=revisionrevision=1070523

 Honor SKIP_ITERATION FacesContext property
 --

 Key: TRINIDAD-2030
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2030
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andy Schwartz
Priority: Minor
 Fix For: 2.0.0-beta-2

 Attachments: trinidad-skip-iteration.patch


 As discussed in this MyFaces core issue:
 MYFACES-3036 Support SKIP_ITERATION FacesContext property
 The JSF-314 EG (and members of Mojarra and MyFaces) agreed to use the 
 javax.faces.visit.SKIP_ITERATION FacesContext property (during the 2.0 
 timeframe) to indicate that a tree visit should not trigger iteration in 
 iterating components like UIData/UIRepeat.  Opening this issue to request 
 that iterating Trinidad components (UIXIterator, UIXCollection) honor this 
 property as well.
 Note that Trinidad already handles this centrally in 
 UIXComponent.visitChildren:
   // determine whether this visit should be iterating.  If it shouldn't, 
 don't
   // even call the protected hook.  We currently don't iterate during the
   // restore view phase when we are visiting all of the components.
   boolean noIterate = (visitContext.getIdsToVisit() == 
 VisitContext.ALL_IDS) 
   (context.getCurrentPhaseId() == 
 PhaseId.RESTORE_VIEW);
   doneVisiting =  (noIterate)
 ? uixParentComponent._visitAllChildren(visitContext, 
 callback)
 : uixParentComponent.visitChildren(visitContext, 
 callback);
 This issue is requesting that we enhance the above noIterate test to also 
 check the SKIP_ITERATION property.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (TRINIDAD-2030) Honor SKIP_ITERATION FacesContext property

2011-02-13 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-2030:


Status: Patch Available  (was: Open)

 Honor SKIP_ITERATION FacesContext property
 --

 Key: TRINIDAD-2030
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2030
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andy Schwartz
Priority: Minor
 Attachments: trinidad-skip-iteration.patch


 As discussed in this MyFaces core issue:
 MYFACES-3036 Support SKIP_ITERATION FacesContext property
 The JSF-314 EG (and members of Mojarra and MyFaces) agreed to use the 
 javax.faces.visit.SKIP_ITERATION FacesContext property (during the 2.0 
 timeframe) to indicate that a tree visit should not trigger iteration in 
 iterating components like UIData/UIRepeat.  Opening this issue to request 
 that iterating Trinidad components (UIXIterator, UIXCollection) honor this 
 property as well.
 Note that Trinidad already handles this centrally in 
 UIXComponent.visitChildren:
   // determine whether this visit should be iterating.  If it shouldn't, 
 don't
   // even call the protected hook.  We currently don't iterate during the
   // restore view phase when we are visiting all of the components.
   boolean noIterate = (visitContext.getIdsToVisit() == 
 VisitContext.ALL_IDS) 
   (context.getCurrentPhaseId() == 
 PhaseId.RESTORE_VIEW);
   doneVisiting =  (noIterate)
 ? uixParentComponent._visitAllChildren(visitContext, 
 callback)
 : uixParentComponent.visitChildren(visitContext, 
 callback);
 This issue is requesting that we enhance the above noIterate test to also 
 check the SKIP_ITERATION property.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2030) Honor SKIP_ITERATION FacesContext property

2011-02-13 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994181#comment-12994181
 ] 

Andy Schwartz commented on TRINIDAD-2030:
-

One comment on the attached patch...

Originally I was thinking that we would skip iteration if either the 
SKIP_ITERATION hint is specified *or* we are in the restore view phase.  
However, after seeing the following MyFaces core issue:

MYFACES-3033 Improve DebugPhaseListener for UIData and SKIP_ITERATION
https://issues.apache.org/jira/browse/MYFACES-3033

It seems that we want to allow iterating visits during the restore view phase, 
if only because the MyFaces DebugPhaseListener attempts to do this.  As such, 
the patch removes the previous phase check and only checks for the 
SKIP_ITERATION hint.



 Honor SKIP_ITERATION FacesContext property
 --

 Key: TRINIDAD-2030
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2030
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andy Schwartz
Priority: Minor
 Attachments: trinidad-skip-iteration.patch


 As discussed in this MyFaces core issue:
 MYFACES-3036 Support SKIP_ITERATION FacesContext property
 The JSF-314 EG (and members of Mojarra and MyFaces) agreed to use the 
 javax.faces.visit.SKIP_ITERATION FacesContext property (during the 2.0 
 timeframe) to indicate that a tree visit should not trigger iteration in 
 iterating components like UIData/UIRepeat.  Opening this issue to request 
 that iterating Trinidad components (UIXIterator, UIXCollection) honor this 
 property as well.
 Note that Trinidad already handles this centrally in 
 UIXComponent.visitChildren:
   // determine whether this visit should be iterating.  If it shouldn't, 
 don't
   // even call the protected hook.  We currently don't iterate during the
   // restore view phase when we are visiting all of the components.
   boolean noIterate = (visitContext.getIdsToVisit() == 
 VisitContext.ALL_IDS) 
   (context.getCurrentPhaseId() == 
 PhaseId.RESTORE_VIEW);
   doneVisiting =  (noIterate)
 ? uixParentComponent._visitAllChildren(visitContext, 
 callback)
 : uixParentComponent.visitChildren(visitContext, 
 callback);
 This issue is requesting that we enhance the above noIterate test to also 
 check the SKIP_ITERATION property.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3036) Support SKIP_ITERATION FacesContext property

2011-02-08 Thread Andy Schwartz (JIRA)

Support SKIP_ITERATION FacesContext property


 Key: MYFACES-3036
 URL: https://issues.apache.org/jira/browse/MYFACES-3036
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.0.3
Reporter: Andy Schwartz
Priority: Minor


In the following jsr-314-open thread:

http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-June/000200.html

Members of the Mojarra team, MyFaces team and EG discussed a temporary 
workaround for the lack of a proper VisitHint.SKIP_ITERATION API in JSF 2.0.x.  
We agreed to use a FacesContext property to address this case until a new 
VisitHint enum value could be added in 2.1.

Logging this issue to request that we add support for the FacesContext property 
(javax.faces.visit.SKIP_ITERATION) in MyFaces 2.0.x to allow tree visits to 
be performed without forcing iterating components (like UIData/UIRepeat) to 
iterate over all rows.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3037) Children of iterating components receive multiple PostRestoreStateEvents

2011-02-08 Thread Andy Schwartz (JIRA)

Children of iterating components receive multiple PostRestoreStateEvents


 Key: MYFACES-3037
 URL: https://issues.apache.org/jira/browse/MYFACES-3037
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.3
Reporter: Andy Schwartz


We currently use a tree visit to deliver PostRestoreStateEvents.  By default 
tree visits will cause iterating components (such as UIData/UIRepeat) to 
iterate over all visible rows in the model.  This results in children being 
visited once per iteration - and thus PostRestoreStateEvents re-delivered for 
each row.

An interesting side effect of this is that component binding setters will be 
evaluated multiple times.  For example, in a case like this:


 h:dataTable value=#{someModel} var=row
   h:column
 h:ouputText binding=bean.foo/
   /h:column
 /h:dataTable

The binding setter (eg. setFoo()) is called multiple times (once per row) in 
2.0.  In 1.2 this was only called one time.

Note that a solution for the following issue:

MYFACES-3036 Support SKIP_ITERATION FacesContext property

Would make fixing this issue simple.  The tree visit that we use for 
PostRestoreStateEvent delivery would simply specify the SKIP_ITERATION hint.


-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TRINIDAD-2030) Honor SKIP_ITERATION FacesContext property

2011-02-08 Thread Andy Schwartz (JIRA)

Honor SKIP_ITERATION FacesContext property
--

 Key: TRINIDAD-2030
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2030
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andy Schwartz
Priority: Minor


As discussed in this MyFaces core issue:

MYFACES-3036 Support SKIP_ITERATION FacesContext property

The JSF-314 EG (and members of Mojarra and MyFaces) agreed to use the 
javax.faces.visit.SKIP_ITERATION FacesContext property (during the 2.0 
timeframe) to indicate that a tree visit should not trigger iteration in 
iterating components like UIData/UIRepeat.  Opening this issue to request that 
iterating Trinidad components (UIXIterator, UIXCollection) honor this property 
as well.

Note that Trinidad already handles this centrally in UIXComponent.visitChildren:

  // determine whether this visit should be iterating.  If it shouldn't, 
don't
  // even call the protected hook.  We currently don't iterate during the
  // restore view phase when we are visiting all of the components.
  boolean noIterate = (visitContext.getIdsToVisit() == 
VisitContext.ALL_IDS) 
  (context.getCurrentPhaseId() == PhaseId.RESTORE_VIEW);

  doneVisiting =  (noIterate)
? uixParentComponent._visitAllChildren(visitContext, 
callback)
: uixParentComponent.visitChildren(visitContext, 
callback);

This issue is requesting that we enhance the above noIterate test to also 
check the SKIP_ITERATION property.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3033) Improve DebugPhaseListener for UIData and SKIP_ITERATION

2011-02-08 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992310#comment-12992310
 ] 

Andy Schwartz commented on MYFACES-3033:


Trinidad also suppress table iteration based on the phase id.  From 
UIXComponent:

  // determine whether this visit should be iterating.  If it shouldn't, 
don't
  // even call the protected hook.  We currently don't iterate during the
  // restore view phase when we are visiting all of the components.
  boolean noIterate = (visitContext.getIdsToVisit() == 
VisitContext.ALL_IDS) 
  (context.getCurrentPhaseId() == PhaseId.RESTORE_VIEW);

  doneVisiting =  (noIterate)
? uixParentComponent._visitAllChildren(visitContext, 
callback)
: uixParentComponent.visitChildren(visitContext, 
callback);

However, as of the following MyFaces fix:

MYFACES-3036 Support SKIP_ITERATION FacesContext property
https://issues.apache.org/jira/browse/MYFACES-3036

Both MyFaces and Mojarra support the javax.faces.visit.SKIP_ITERATION 
FacesContext property in their 2.0.x code bases.  This means that iterating 
components can now decide whether or not to iterate based on the presence of 
this property.

I have logged the following issue against Trinidad on this topic:

TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property
https://issues.apache.org/jira/browse/TRINIDAD-2030

It would be good if RichFaces would also take advantage of this.  This should 
avoid the problem reported here - ie. if iterating components check for the 
SKIP_ITERATION property rather checking for restore view phase, the 
DebugPhaseListener's tree visit should be able to safely evaluate EL.




 Improve DebugPhaseListener for UIData and SKIP_ITERATION
 

 Key: MYFACES-3033
 URL: https://issues.apache.org/jira/browse/MYFACES-3033
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 2.1.0
Reporter: Martin Kočí

 h:dataTable var=row 
   h:column
 h:outputText rendered=#{bean.isRendered(row)}
 There is new VisitHint.SKIP_ITERATION in JSF 2.1. If that hint is used UIData 
 iterate over children in flat manner and therefore no row is available - 
 bean.isRendered(row) obtains null as parameter and NPE can happen. One 
 problem in this situation is a component tree walk before RESTORE_VIEW from 
 DebugPhaseListener:
 java.lang.NullPointerException
 foo.bazz.bean.isRendered
 ...
 at 
 org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:85)
 at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:260)
 at javax.faces.component.UIComponentBase.isRendered
 ...
 at javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:991)
 at 
 org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener._doTreeVisit(DebugPhaseListener.java:310)
 at 
 org.apache.myfaces.view.facelets.tag.ui.DebugPhaseListener.afterPhase(DebugPhaseListener.java:286)

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3024) MyFaces hangs when converting 2.2250738585072012e-308

2011-02-04 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12990670#comment-12990670
 ] 

Andy Schwartz commented on MYFACES-3024:


There is an addendum to the original article that mentions that equivalent 
forms of the same value also trigger the problem:

 As pointed out in the comments below, equivalent forms of the number
 cause the problem as well; examples:
 
 0.00022250738585072012e-304 (decimal point placement)
 002.2250738585072012e-308 (leading zeros)
 2.22507385850720120e-308 (trailing zeros)
 2.2250738585072012e-00308 (leading zeros in the exponent)
 2.225073858507201299781e-308 (superfluous digits beyond digit 17)

This makes a robust fix more difficult.

 MyFaces hangs when converting 2.2250738585072012e-308
 -

 Key: MYFACES-3024
 URL: https://issues.apache.org/jira/browse/MYFACES-3024
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Matthias Weßendorf
Priority: Critical

 I read
 http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/
 Nice! and it even works with JSF :-)
 Looking at the MyFaces (double) converter, I see Double.valueOf() 
 Now, I did a quick check, with Trinidad (disabled client-side validation) and 
 MyFaces (since Trinidad calls super.getAsObject()).
 Entering 2.2250738585072012e-308 into a field, that has a double converter 
 is keeping my JVM _really_ busy ! :)
 Sweet!

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-2019) ClassCastException on StampState$TableState when using Mojarra

2011-01-24 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985875#action_12985875
 ] 

Andy Schwartz commented on TRINIDAD-2019:
-

We ran into another case where Mojarra was incorrectly inserting a UIPanel 
wrapper inside of a facet.  See:

http://java.net/jira/browse/JAVASERVERFACES-1726

Is it possible that you are running against a version of Mojarra that does not 
include this fix (ie. pre-2.0.4)?

Since the incorrect insertion of UIPanel components can have all sorts of 
unexpected side effects, I would recommend that we attempt to secure a fix for 
this problem at the Mojarra level rather than working around this in Trinidad. 

 ClassCastException on StampState$TableState when using Mojarra
 --

 Key: TRINIDAD-2019
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2019
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-alpha, 2.0.0-alpha-2
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
 Attachments: TRINIDAD-2019.patch


 When  a UIX Collection object is put inside of a component (such as a 
 switcher which has a list of facets) and it then put inside of another panel 
 collection, Mojarra can sometimes change the heirarcy of the stamped 
 component by inserting a UIPanel during a PPR.  This has the effect of 
 generating a ClassCastException when StampState$TableState tries to cast the 
 component to a UIXCollection so that table-in-table can be supported.
 This issue ONLY happens in this specific circumstance where the switcher has 
 only one component in the facet and we have a collection inside of another 
 collection.  Although this is a bug with Mojarra, the patch is fairly 
 straight forward and if we see a UIPanel instead of a UIXCollection, we 
 should, instead, sent the StampState to the UIPanel's single child.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization

2011-01-10 Thread Andy Schwartz (JIRA)

TrinidadFilterImpl FacesContext initialization
--

 Key: TRINIDAD-2002
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Priority: Minor


ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses 
this to perform early configuration/initialization work.  In particular, we use 
the ApplicationFactory to get at the Application instance and then create/add 
converters to the Application.

This works fine on Mojarra 2.0.x releases.

However, this fails in both:

- MyFaces 2.0.x
- Mojarra 2.1.x

In both cases, the reason for the failure is that access to the FacesContext is 
required but is not yet available.  In MyFaces 2.0.x, the 
FacesContext/ExternalContext is required by 
Application.createConverter()/setConverterProperties() in order to determine 
the value of the 
javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE context 
parameter.  In Mojarra 2.1.x, the ApplicationFactory requires access to the 
FacesContext in order to create the Application instance.

While we can work around this issue at the ADF Faces level, TrinidadFilterImpl 
is already well positioned to address this - ie. TrinidadFilterImpl has access 
to  the PseudoFacesContext and already sets this up for other cases (eg. for 
Configurator.beginRequest()).

I am logging this issue to request that we take advantage of the existing 
support that TrinidadFilterImpl/PseudoFacesContext provides for early 
FacesContext access and extend this to TrinidadFilterImpl.init().



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization

2011-01-10 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12979792#action_12979792
]

Andy Schwartz commented on TRINIDAD-2002:
-

This patch:

https://issues.apache.org/jira/secure/attachment/12467925/TRINIDAD-2002.patch

Demonstrates how we might implement this change.

TrinidadFilterImpl FacesContext initialization
--

Key: TRINIDAD-2002
URL: https://issues.apache.org/jira/browse/TRINIDAD-2002
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Priority: Minor
Attachments: TRINIDAD-2002.patch

ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and
uses this to perform early configuration/initialization work. In particular,
we use the ApplicationFactory to get at the Application instance and then
create/add converters to the Application.
This works fine on Mojarra 2.0.x releases.
However, this fails in both:
- MyFaces 2.0.x
- Mojarra 2.1.x
In both cases, the reason for the failure is that access to the FacesContext
is required but is not yet available. In MyFaces 2.0.x, the
FacesContext/ExternalContext is required by
Application.createConverter()/setConverterProperties() in order to determine
the value of the
javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE context
parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the
FacesContext in order to create the Application instance.
While we can work around this issue at the ADF Faces level,
TrinidadFilterImpl is already well positioned to address this - ie.
TrinidadFilterImpl has access to the PseudoFacesContext and already sets
this up for other cases (eg. for Configurator.beginRequest()).
I am logging this issue to request that we take advantage of the existing
support that TrinidadFilterImpl/PseudoFacesContext provides for early
FacesContext access and extend this to TrinidadFilterImpl.init().

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization

2011-01-10 Thread Andy Schwartz (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andy Schwartz updated TRINIDAD-2002:

Status: Patch Available (was: Open)

TrinidadFilterImpl FacesContext initialization
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1966) DISABLE_CONTENT_COMPRESSION_IN_PRODUCTION_STAGE message incorrect

2010-12-01 Thread Andy Schwartz (JIRA)

DISABLE_CONTENT_COMPRESSION_IN_PRODUCTION_STAGE message incorrect
-

 Key: TRINIDAD-1966
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1966
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
Reporter: Andy Schwartz
Priority: Minor


Trinidad logs a message to warn when DISABLE_CONTENT_COMPRESSION is enabled in 
production project stage.  The wording of this message is incorrect.  From 
LoggerBundle.xrts:

!-- DISABLE_CONTENT_COMPRESSION_IN_PRODUCTION_STAGE --
resource key=DISABLE_CONTENT_COMPRESSION_IN_PRODUCTION_STAGEYour 
environment is configured as productio\
n and Apache Trinidad is running with debug javascript. See the 
org.apache.myfaces.trinidad.DEBUG_JAVASCRI\
PT parameter in /WEB-INF/web.xml/resource

This should reference the DISABLE_CONTENT_COMPRESSION context parameter - not 
DEBUG_JAVASCRIPT.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1790) Trinidad 2: Component Bindings are not executed during postback

2010-11-15 Thread Andy Schwartz (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932127#action_12932127
 ] 

Andy Schwartz commented on TRINIDAD-1790:
-

I tested this against the latest Trinidad trunk and MyFaces 2.0.0.3-SNAPSHOT 
and no longer see the problem.  The component binding/view root caching problem 
has been resolved by the following MyFaces fix:

https://issues.apache.org/jira/browse/MYFACES-2750

I suspect that we can close up this Trinidad issue now.  (FWIW, similar issue, 
TRINIDAD-1786 is now closed.)


 Trinidad 2: Component Bindings are not executed during postback
 ---

 Key: TRINIDAD-1790
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1790
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
Reporter: Max Starets

 To reproduce, run testRelativePartialTriggers.jspx an click the first Make 
 table Pink button.  Note that the table component is being PPR-ed,
 but the inline style remains the same. This happens because 'table1' in the 
 backing bean is null. The setter method never gets called.
 The most likely cause is the fact that JSF RI moved the code for binding 
 execution out of the lifecycle implementation into the PostRestoreViewState 
 event processing. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1892) Support source template for JSP tag generation

2010-08-25 Thread Andy Schwartz (JIRA)

Support source template for JSP tag generation
--

 Key: TRINIDAD-1892
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1892
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz


Trinidad's GenerateComponentMojo allows a base source template to be specified 
for components that are generated.  The contents of the template file are 
merged with the generated contents to form the complete component class.

Trinidad's GenerateJspTaglibsMojo, while containing some code that hints at 
this support, eg:

  private class IfComponentModifiedFilter extends ComponentFilter
  {
protected boolean accept(
  ComponentBean component)
{
  String tagClass = component.getTagClass();
  String sourcePath = Util.convertClassToSourcePath(tagClass, .java);
  String templatePath = Util.convertClassToSourcePath(tagClass, 
Template.java);
  File targetFile = new File(generatedSourceDirectory, sourcePath);
  File templateFile = new File(templateSourceDirectory, templatePath);

  // accept if templateFile is newer or component has been modified
  return (templateFile.lastModified()  targetFile.lastModified() ||
  component.isModifiedSince(targetFile.lastModified()));
}
  }


Does not appear to fully support this.

Opening this issue to request that we enhance GenerateJspTaglibsMojo to include 
support for allowing a base template source file to be specified for generated 
component tags.  Without this, if any tag customization is necessary, the tag 
generation tool cannot be used - ie. the entire tag must be written from 
scratch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1669) Improve transient memory consumption of UIXComponentBase.getClientId()

2010-08-10 Thread Andy Schwartz (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Schwartz updated TRINIDAD-1669:


Status: Patch Available  (was: Open)

 Improve transient memory consumption of UIXComponentBase.getClientId()
 --

 Key: TRINIDAD-1669
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1669
 Project: MyFaces Trinidad
  Issue Type: Improvement
 Environment: All
Reporter: Blake Sullivan
Assignee: Blake Sullivan
 Attachments: trinidad-1669.patch

   Original Estimate: 72h
  Remaining Estimate: 72h

 Calling UIXComponentBase.getClientId consumes a great deal of transient 
 memory.  Under light loads, this doesn't matter--the objects are extremely 
 short-lived and are allocated out of the first-generation heap.  However, 
 when large numbers of users are accessing the server simultaneously these 
 allocations contribute to first-generation heap exhaustion and 
 first-generation heap GC's when deeply nested NamingContainers are used.
 There are two reasons that large amounts of transient memory is consumed in 
 these cases:
 1) UIXComponentBase doesn't cache clientIds because the clientIds are partly 
 determined by the component's ancestors and there are cases (such as 
 stamping), where multiple clientIds may map to a single component instance
 2) clientIds are generated recursively by:
 a) calling getContainerClientId() and appending the NamingContainer separator 
 and the component's id to the result
 b) getContainerClientId() is implemented by calling getContainerClientId() 
 and doing likewise
 So, each NamingContainer in the hierarchy is going to:
 1) Get it's ancestor's container clientId and if one exists
 2) Get it's id attribute
 3) Allocate a StringBuilder to contain these two Strings, append them together
 4) Convert the StringBuilder to a String and return the result
 An earlier JIRA used a ThreadLocal StringBuilder to remove the StringBuilder 
 allocation in step 3) in the common case, halving the transient memory usage, 
 however we still have the String allocations made necessary by the use of   
 String getContainerClientId(FacesContext context, UIComponent child).
 For a 20 row table containing 10 columns nested four NamingContainers deep 
 (counting the table as one of these), we end up with 1000 String allocations, 
 which wouldn't necessarily be that bad if the size of the Strings wasn't 
 increasing and if the Rendering code was the only code calling getClientId() 
 (InvokeOnComponent is the primary culprit here, though replacing 
 invokeOnComponent calls with visitTree calls improves things).
 The proposed solution is to replace generating new Strings at each 
 NamingContainer level with appending the NamingContainer ids into a 
 StringBuilder (in fact, the shared StringBuilder) passed to the appending 
 code--a String is only generated when the returning the value from 
 getClientId().  In scalability testing, this change has been worth about 8%.
 The advantages of this approach are:
 1) If the component code compiles, the code will almost certainly work 
 correctly
 2) It clientId caching is also used, this approach speeds up generation of 
 the cached result
 The disadvatanges of this approach is:
 1) Any overrides of getClientId() or getContainerClientId() must be changed 
 to overrides of appendClientId() or appendContainerClientId().  To enforce 
 this, getClientId() and getContainerClientId() are made final on 
 UIXComponentBase.  This, is of course, an incompatible api change
 The new/changed apis on UIXComponentBase:
   /**
* Appends the container's clientId for the requesting child to the 
 StringBuilder, returning the passed in StringBuilder.
* Component implementations are only allowed to mutate the StringBuilder 
 other than to append.
* Subclasses that wish to modify the clientIds returned for their children 
 should override this method rather than
* codegetContainerClientId/code.
* @param context FacesContext
* @param child Optional child component that is requesting the container's
*  clientId
* @param clientIdAppendable StringBuilder to append the container's 
 clientId to
* @see #getContainerClientId(FacesContext, UIComponent)
*/
   public StringBuilder appendContainerClientId(
 FacesContext context,
 UIComponent child,
 StringBuilder clientIdAppendable)
   /**
* Appends the clientId of this component to the StringBuilder, returning 
 the passed in StringBuilder.
* Component implementations typically only mutate the StringBuilder to 
 append.
* Subclasses that wish to modify the clientIds that they return should 
 override this method rather than
* codegetClientId/code.
* @param context FacesContext
* @param

[jira] Created: (TRINIDAD-1850) Remove dependency on Shale Test

2010-07-13 Thread Andy Schwartz (JIRA)

Remove dependency on Shale Test
---

 Key: TRINIDAD-1850
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1850
 Project: MyFaces Trinidad
  Issue Type: Task
Reporter: Andy Schwartz


Trinidad's unit tests are based on Apache Shale Test, which is now a retired 
project.  Trinidad should cut over to MyFaces Test in order to avoid the 
dependency on a project that is no longer being actively developed.

Note that the Trinidad unit tests are currently failing when run against 
Mojarra 2.0.3 due to incompatibilities between Shale Test and JSF 2.0.  I am 
working with the Mojarra team to see whether they can provide a workaround for 
this particular issue.  However, the current strategy of relying on Shale Test 
is not an acceptable long-term solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1851) Test failures when building against Mojarra 2.0.3

2010-07-13 Thread Andy Schwartz (JIRA)

Test failures when building against Mojarra 2.0.3
-

 Key: TRINIDAD-1851
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1851
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Andy Schwartz


Aside from the Shale Test/Mojarra 2.0.3 incompatibilities mentioned here:

https://issues.apache.org/jira/browse/TRINIDAD-1850

Trinidad is also hitting a small number of unrelated test failures:

Matthias logged the following Mojarra bug to track this:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1584

However, the problem needs to be fixed at the Trinidad level, not at Mojarra.

The issue is that the UIComponent mock objects used by these tests do not 
provide access to getValueExpression(), which is now called by these tests as 
of Mojarra 2.0.3.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1800) NavigationHandlerImpl does not implement ConfigurableNavigationHandler

2010-04-27 Thread Andy Schwartz (JIRA)

NavigationHandlerImpl does not implement ConfigurableNavigationHandler
--

 Key: TRINIDAD-1800
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1800
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz


Trinidad's NavigationHandler implementation needs to implement the 
ConfigurableNavigationHandler contract.  WIthout this, new JSF2 functionality 
such as pre-emptive navigation will fail.

Note that the implementation should be relatively straightforward - ie. we just 
need to delegate through to the underlying NavigationHandler, which typically 
will be an instance of ConfigurableNavigationHandler as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

1 2 >

1 - 100 of 133 matches

Mail list logo