from:"Scott O'Bryan"

Scott O'Bryan created TRINIDAD-2498:
---

 Summary: ResourceServlet does not preserve outgoing headers from 
URLConnection.
 Key: TRINIDAD-2498
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2498
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan


The ResourceServlet relies on ResourceHandlers to supply things like graphics 
images and the like to the browser.  For most trinidad resources, these will be 
local resources where headers other the cache-control and whatnot are 
unimportant.

There might be ResourceHandler's, however, which do need these headers to be 
preserved, for instance if a content-disposition header is returned.  Since the 
ResourceHandler provides a URLConnection, and there is header support built 
into the URLConnection object, then ResourceServlet should be enhanced to 
preserve a white-list of these headers.

For current implementation which don't have any extra headers, everything 
should continue to work as it does today.



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

[jira] [Updated] (TRINIDAD-2498) ResourceServlet does not preserve outgoing headers from URLConnection.


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

Scott O'Bryan updated TRINIDAD-2498:


Status: Patch Available  (was: Open)

 ResourceServlet does not preserve outgoing headers from URLConnection.
 --

 Key: TRINIDAD-2498
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2498
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan

 The ResourceServlet relies on ResourceHandlers to supply things like graphics 
 images and the like to the browser.  For most trinidad resources, these will 
 be local resources where headers other the cache-control and whatnot are 
 unimportant.
 There might be ResourceHandler's, however, which do need these headers to be 
 preserved, for instance if a content-disposition header is returned.  Since 
 the ResourceHandler provides a URLConnection, and there is header support 
 built into the URLConnection object, then ResourceServlet should be enhanced 
 to preserve a white-list of these headers.
 For current implementation which don't have any extra headers, everything 
 should continue to work as it does today.



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

[jira] [Resolved] (TRINIDAD-2498) ResourceServlet does not preserve outgoing headers from URLConnection.


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

Scott O'Bryan resolved TRINIDAD-2498.
-

   Resolution: Fixed
Fix Version/s: 2.1.1-core

 ResourceServlet does not preserve outgoing headers from URLConnection.
 --

 Key: TRINIDAD-2498
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2498
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
 Fix For: 2.1.1-core

 Attachments: trin-patch.patch


 The ResourceServlet relies on ResourceHandlers to supply things like graphics 
 images and the like to the browser.  For most trinidad resources, these will 
 be local resources where headers other the cache-control and whatnot are 
 unimportant.
 There might be ResourceHandler's, however, which do need these headers to be 
 preserved, for instance if a content-disposition header is returned.  Since 
 the ResourceHandler provides a URLConnection, and there is header support 
 built into the URLConnection object, then ResourceServlet should be enhanced 
 to preserve a white-list of these headers.
 For current implementation which don't have any extra headers, everything 
 should continue to work as it does today.



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

[jira] [Commented] (TRINIDAD-2497) Code changes for JDK8 Compatibility issue

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

Scott O'Bryan commented on TRINIDAD-2497:
-

I tried building these manually and then building against jdk8 and it didn't
work. It appears clirr-runner is unable to work properly. Even with the
change it doesn't break JDK7. I verified everything built with jdk7.

Code changes for JDK8 Compatibility issue
-

Key: TRINIDAD-2497
URL: https://issues.apache.org/jira/browse/TRINIDAD-2497
Project: MyFaces Trinidad
Issue Type: Bug
Components: Build
Affects Versions: 2.1.0-core
Reporter: Avin Goyal
Attachments: JDK8BuildIssue.patch

While building in jdk8, the plugin maven-i18n-plugin in trinidad plugin
project, had the following problems:
1. The methods are no longer static in sun.util.resources.LocaleData.java (we
are using to get the resourceBundles). We are using reflection to invoke the
methods. Earlier we were passing null. But now, since the methods are no
longer static, we have to pass the instance of LocaleData to invoke the
methods.
2. There is a change in the DateTimePatterns value in JAVA8. Till JDK7, it
also had Time and Date patterns.
In JDK8, it contains only one string: {1} {0}.
In order to get the old value back, we have to combine the values from these
three keys: TimePatterns, DatePatterns, DateTimePatterns
Also, modifying pom.xml of maven-i18n-plugin to change maven-compiler-plugin
source and target version number to 1.6 from 1.4

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

[jira] [Updated] (TRINIDAD-2497) Code changes for JDK8 Compatibility issue


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

Scott O'Bryan updated TRINIDAD-2497:


Status: Open  (was: Patch Available)

 Code changes for JDK8 Compatibility issue
 -

 Key: TRINIDAD-2497
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2497
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Affects Versions: 2.1.0-core
Reporter: Avin Goyal
 Attachments: JDK8BuildIssue.patch


 While building in jdk8, the plugin maven-i18n-plugin in trinidad plugin 
 project, had the following problems:
 1. The methods are no longer static in sun.util.resources.LocaleData.java (we 
 are using to get the resourceBundles). We are using reflection to invoke the 
 methods. Earlier we were passing null. But now, since the methods are no 
 longer static, we have to pass the instance of LocaleData to invoke the 
 methods. 
 2. There is a change in the DateTimePatterns value in JAVA8. Till JDK7, it 
 also had Time and Date patterns.
 In JDK8, it contains only one string: {1} {0}.
 In order to get the old value back, we have to combine the values from these 
 three keys: TimePatterns, DatePatterns, DateTimePatterns
 Also, modifying pom.xml of maven-i18n-plugin to change maven-compiler-plugin 
 source and target version number to 1.6 from 1.4



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

[jira] [Created] (TRINIDAD-2491) ResourceServlet does not open connection before copying headers

2014-07-07 Thread Scott O'Bryan (JIRA)

Scott O'Bryan created TRINIDAD-2491:
---

 Summary: ResourceServlet does not open connection before copying 
headers
 Key: TRINIDAD-2491
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2491
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan


The resource servlet is a staple of the trinidad framework able to retrieve 
resources through a series of handlers.  It's based off a servlet known as the 
ResourceServlet.

In the ResourceServlet, we have the following code:

// Stream the resource contents to the servlet response
URLConnection connection = url.openConnection();
connection.setDoInput(true);
connection.setDoOutput(false);
 
_setHeaders(connection, response, loader);

InputStream in = connection.getInputStream();
OutputStream out = response.getOutputStream();

The _setHeaders function pulls some of the headers off of the connection (if 
they are available) and copies them to the response.  The problem here, 
however, is that by contract, the connection need not yet have this information 
until after a URLConnection.connect() or the URLConnection.getInputStream() is 
returned.  This means, when the headers are set, they may not yet be available 
depending on connection type.  To more accurately handle the URLConnection 
contract, we should explicitly 'connect' the URLConnection before trying to 
retrieve the headers.



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

[jira] [Updated] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

2014-06-10 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan updated TRINIDAD-2445:


Status: Open  (was: Patch Available)

 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch, filterExceptions.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter

2014-06-10 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2445:
-

I'm applying the patch now for the reverted code.  It's obvious to me, though, 
that some more work needs to be done so I'm going to reopen the JIRA ticket so 
the final fix can be added.

 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch, filterExceptions.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Comment Edited] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter


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

Scott O'Bryan edited comment on TRINIDAD-2445 at 5/28/14 5:15 PM:
--

Silly question but I'm wondering WHY this was needed?  The bug is not very 
informative.


was (Author: darkarena):
Silly question but I'm wondering WHY this was needed.  The bug is not very 
informative.

 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Reopened] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter


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

Scott O'Bryan reopened TRINIDAD-2445:
-


 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter


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

Scott O'Bryan commented on TRINIDAD-2445:
-

Silly question but I'm wondering WHY this was needed.  The bug is not very 
informative.

 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Commented] (TRINIDAD-2445) Prevent exceptions from propagating out of the ServletFilter


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

Scott O'Bryan commented on TRINIDAD-2445:
-

The reason I reopened this is because this is preventing other filters from 
getting the errors if they go before the TrinidadFilter.  Please provide a 
description about what the issue is that this bug is trying to fix so that we 
can assess how to keep this fix but also provide the logic that's needed by 
another custom filter.

 Prevent exceptions from propagating out of the ServletFilter
 

 Key: TRINIDAD-2445
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2445
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.1-core
Reporter: Arjun Vade
Assignee: Jeanne Waldman
 Fix For: 2.1.1-core

 Attachments: 17191718.patch


 Any exceptions from the Trinidad code that runs before JSF lifecycle that 
 propagates to application server layer may result in the end user not seeing 
 a meaningful error message in UI.
 Solution: Trinidad code that runs before the JSF lifecycle shouldn't allow 
 exceptions to propagate out of the ServletFilter.
 The fix is simply to add code to our various ServletFilters to trap the 
 errors at that point before the errors propagate out.



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

[jira] [Deleted] (PORTLETBRIDGE-235) Security Vulnerability exposed via viewId related request parameters.

2014-05-20 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan deleted PORTLETBRIDGE-235:



 Security Vulnerability exposed via viewId related request parameters. 
 --

 Key: PORTLETBRIDGE-235
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-235
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Reporter: Ross Clewley
Assignee: Scott O'Bryan
Priority: Critical

 The Portlet Bridge has a security vulnerability in which in which the request 
 parameters _jsfBridgeViewId,  __jpfbJSFTARGET and __jpfbJSFResTARGET are not 
 restricted to valid filename characters. 



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

[jira] [Updated] (TRINIDAD-2467) FacesMessageWrapper and Skin Addition enhancements

2014-04-30 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan updated TRINIDAD-2467:


   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Scott O'Bryan
   Status: Resolved  (was: Patch Available)

Thanks for the patch

 FacesMessageWrapper and Skin Addition enhancements
 --

 Key: TRINIDAD-2467
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2467
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure, Skinning
Affects Versions: 2.1.1-core
Reporter: Venkata Guddanti
Assignee: Scott O'Bryan
 Fix For: 2.1.1-core

 Attachments: facesMessageAndSkinAddition.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 Minor enhancements to the FacesMessageWrapper and Skin Additions for  
 dependent frameworks. 
 1. Make FacesMessageWrapper externalizable for better serialization support.
 2. Implement Comparable for the SkinAdditions
 3. Miscellaneous minor changes



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

[jira] [Resolved] (TRINIDAD-2439) Plugable configuration parameter provider

2014-04-16 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2439.
-

   Resolution: Fixed
Fix Version/s: 2.1.1-core

 Plugable configuration parameter provider
 -

 Key: TRINIDAD-2439
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2439
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
 Environment: All
Reporter: David Schneider
Assignee: Scott O'Bryan
 Fix For: 2.1.1-core

 Attachments: trinidad-config.diff


 The Trinidad framework currently uses servlet context initialization 
 parameter values specified in the web.xml file for supplying configuration 
 parameters to the runtime.  In some applications and environments it is 
 desirable to be able to supply configuration parameters from other sources 
 (e.g a database table, MBean, etc.).  This enhancement proposes to create an 
 interface abstraction for fetching configuration parameter values along with 
 a plugable framework for configuration value providers.  This will allow 
 applications to plug in their own value providers that fetch values from 
 different sources.  A default value provider that fetches servlet context 
 initialization parameter values that preserves existing behavior will also be 
 provided.



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

[jira] [Created] (TRINIDAD-2456) URL Escaping doubly escapes some urls containing %

2014-02-25 Thread Scott O'Bryan (JIRA)

Scott O'Bryan created TRINIDAD-2456:
---

 Summary: URL Escaping doubly escapes some urls containing %
 Key: TRINIDAD-2456
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2456
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor


An API was added to URLUtils.  This Utility will doubly escape any urls which 
may already have %xx notation in them.



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

[jira] [Reopened] (TRINIDAD-2441) URLUtil to escape a URL and remove invalid characters

2014-02-04 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan reopened TRINIDAD-2441:
-


There was a bug in this utility.  I'm going to check in a fix to remove the 
issue.

 URLUtil to escape a URL and remove invalid characters
 -

 Key: TRINIDAD-2441
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2441
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor
 Fix For: 2.1.1-core


 URLUtils has a number of different types of encodings to aid URL's that go 
 out to the client.  Currently there is no utility to simply remove any 
 invalid characters and encode them using %XX notation.



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

[TRINIDAD] NullPointerException testing Trinidad 2.1.0 (was NullPointerException testing Trinidad 2.1.0)

2014-01-24 Thread Scott O'Bryan

..adding the Trinidad prefix will help get this more traction.

I assume your using the Trinidad Renderkit?  If so, can you make a simple test 
case that illustrates this and file a JIRA ticket?  Maybe in the course of 
making a simple test case, you may figure out what the issue is. ;)
-- 
Scott O'Bryan
Sent with Airmail

On January 24, 2014 at 9:02:17 AM, Cédric Durmont (cdurm...@gmail.com) wrote:

I'm currently testing my trinidad 2.0.x app with Trinidad 2.1.0 / myfaces 2.1.14
I'm having an issue but I'm not sure if it's Trinidad's fault, or MyFaces (or 
mine !)...

When returning from a dialog popup, I have a NullPointerException in 
UIComponentBase.java (myfaces, then) :
protected Renderer getRenderer(FacesContext context)
{
[...]
    RenderKit renderKit = context.getRenderKit();    // context : 
org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit
    renderer = renderKit.getRenderer(getFamily(), rendererType);    // 
exception here

The renderKit variable is null, hence the NPE.
The context object is from Trinidad...

The component that is being rendered at the time of the error is an 
outputScript :

h:outputScript library=js name=convertNumber.js target=head 
id=jsConvertNumber/

Should I file a JIRA ticket ? If so, in Trinidad or MyFaces ?

Regards,
Cedric Durmont

[jira] [Updated] (TRINIDAD-2439) Plugable configuration parameter provider

2014-01-22 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan updated TRINIDAD-2439:


Status: Patch Available  (was: Open)

 Plugable configuration parameter provider
 -

 Key: TRINIDAD-2439
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2439
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
 Environment: All
Reporter: David Schneider
 Attachments: trinidad-config.diff


 The Trinidad framework currently uses servlet context initialization 
 parameter values specified in the web.xml file for supplying configuration 
 parameters to the runtime.  In some applications and environments it is 
 desirable to be able to supply configuration parameters from other sources 
 (e.g a database table, MBean, etc.).  This enhancement proposes to create an 
 interface abstraction for fetching configuration parameter values along with 
 a plugable framework for configuration value providers.  This will allow 
 applications to plug in their own value providers that fetch values from 
 different sources.  A default value provider that fetches servlet context 
 initialization parameter values that preserves existing behavior will also be 
 provided.



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

[jira] [Created] (TRINIDAD-2440) Need utility in URLEncoder to escape illegal characters in a URL using %XX notation

Scott O'Bryan created TRINIDAD-2440:
---

 Summary: Need utility in URLEncoder to escape illegal characters 
in a URL using %XX notation
 Key: TRINIDAD-2440
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2440
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor


URLEncoder has a number of URL encoding utils, but there should be a method to 
us %XX notation for illegal characters with no other encoding.



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

[jira] [Created] (TRINIDAD-2441) URLUtil to escape a URL and remove invalid characters

Scott O'Bryan created TRINIDAD-2441:
---

 Summary: URLUtil to escape a URL and remove invalid characters
 Key: TRINIDAD-2441
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2441
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor


URLUtils has a number of different types of encodings to aid URL's that go out 
to the client.  Currently there is no utility to simply remove any invalid 
characters and encode them using %XX notation.



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

[jira] [Updated] (TRINIDAD-2441) URLUtil to escape a URL and remove invalid characters


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

Scott O'Bryan updated TRINIDAD-2441:


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

 URLUtil to escape a URL and remove invalid characters
 -

 Key: TRINIDAD-2441
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2441
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor
 Fix For: 2.1.1-core


 URLUtils has a number of different types of encodings to aid URL's that go 
 out to the client.  Currently there is no utility to simply remove any 
 invalid characters and encode them using %XX notation.



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

[jira] [Updated] (TRINIDAD-2441) URLUtil to escape a URL and remove invalid characters


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

Scott O'Bryan updated TRINIDAD-2441:


Status: Patch Available  (was: Open)

 URLUtil to escape a URL and remove invalid characters
 -

 Key: TRINIDAD-2441
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2441
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Minor
 Fix For: 2.1.1-core


 URLUtils has a number of different types of encodings to aid URL's that go 
 out to the client.  Currently there is no utility to simply remove any 
 invalid characters and encode them using %XX notation.



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

Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-19 Thread Scott O'Bryan

Good observations Leonardo, thanks.

--
Scott O'Bryan

On November 18, 2013 at 1:08:54 PM, Leonardo Uribe (lu4...@gmail.com) wrote:

Anyway I have just 2 observations that are not blocker for a release in my
opinion.

- trinidad-impl jar has a file in META-INF/trinidad-version.txt with the string
2_0_0_beta_2 . It should be 2.1.0 and this stuff can be generated using maven.

resources
resource
directorysrc/main/resources/directory
excludes
exclude**/*.vm/exclude
exclude**/myfile.properties/exclude
/excludes
/resource
resource
directorysrc/main/resources-filtered/directory
filteringtrue/filtering
/resource

and use velocity to get the project version.

- I ran trinidad-demo and it works, but it seems in
trinidad-components-showcase something is not working well. It could be
something caused by the changes done in trinidad, but it could be good to
investigate what's going on and fix it. Anyway, since the components in
trinidad-demo are working, I set the vote to +1.

regards,

Leonardo Uribe

2013/11/18 Matt Cooper mcoo...@apache.org
+1

On Mon, Nov 18, 2013 at 11:46 AM, jeanne waldman jeanne.wald...@oracle.com
wrote:
compiled and ran a test
+1

On 11/18/2013 10:44 AM PT, Scott O'Bryan wrote:
+1
--
Scott O'Bryan

On November 18, 2013 at 8:25:37 AM, Max Starets (max.star...@oracle.com) wrote:

+1
On 11/15/2013 4:02 PM, Scott O'Bryan wrote:
Hello everyone,

I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0
which is the latest in the Trinidad render kit series. This is the first
release in over a year and contains over a hundred bug fixes since the last
release. All Blocker bugs are currently fixed and all patches request by the
community have been applied. All tests are passing as is the apache-rat:check.

I have generated the tag [1] and have deployed the build artifacts to nexus
[2]. I have also included the source archive [3]. Please take a look at the
Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

Please note:
This vote is majority approval with a minimum of three +1 votes (see [4]).

[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released, and
why..

Thanks,
Scott O'Bryan

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
[2] https://repository.apache.org/content/repositories/orgapachemyfaces-141
[3]
https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes

[RESULTS] [VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-19 Thread Scott O'Bryan

We had the following votes:

+1 (6): Scott O’Bryan (binding), Leonardo Uribe (binding), Matt Cooper
(binding), Jeanne Waldman (binding), Max Starets (binding), Dave Robinson
+0 (0)
-1 (0)

Thanks to all who voted. I’ll go ahead and release the staging repository and
set up jira.

Scott

On November 18, 2013 at 1:08:54 PM, Leonardo Uribe (lu4...@gmail.com) wrote:

Anyway I have just 2 observations that are not blocker for a release in my
opinion.

- trinidad-impl jar has a file in META-INF/trinidad-version.txt with the string
2_0_0_beta_2 . It should be 2.1.0 and this stuff can be generated using maven.

and use velocity to get the project version.

regards,

Leonardo Uribe

2013/11/18 Matt Cooper mcoo...@apache.org
+1

On Mon, Nov 18, 2013 at 11:46 AM, jeanne waldman jeanne.wald...@oracle.com
wrote:
compiled and ran a test
+1

On 11/18/2013 10:44 AM PT, Scott O'Bryan wrote:
+1
--
Scott O'Bryan

On November 18, 2013 at 8:25:37 AM, Max Starets (max.star...@oracle.com) wrote:

+1
On 11/15/2013 4:02 PM, Scott O'Bryan wrote:
Hello everyone,

Please note:
This vote is majority approval with a minimum of three +1 votes (see [4]).

[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released, and
why..

Thanks,
Scott O'Bryan

[jira] [Commented] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI

2013-11-19 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2406:
-

Can we please create a new bug for this issue with the patchs.  The current 
patch was already released.

 externalize skin repositories by using SkinProvider SPI
 ---

 Key: TRINIDAD-2406
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
 Fix For: 2.1.0-core

 Attachments: er-skin-provider-ver7.patch, 
 er-skin-provider-ver8.patch, fc-to-ec.patch, 
 skin-addition-bug-trinidad.patch, spr-bugfix.patch


 Introduce SkinProvider SPI. Users can use this to create their own skip 
 repositories and expose their skins to the skinning framework.
 Provide an API to query skin using skin family, skin id, render kit - This 
 will make use of the existing SkinFactory APIs. Only change here is that it 
 should go over all the available SkinProvider SPIs to find a match.
 Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or 
 skins defined using trinidad-skins.xml).
 Provide an API to list all the available skins from all SkinProvider SPIs and 
 make the skin metadata thus available.
 Make SkinExtension part of public API so that users can use this class to 
 create the Skin objects which they expose through their SkinProvider SPIs



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

[jira] [Comment Edited] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI

2013-11-19 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan edited comment on TRINIDAD-2406 at 11/19/13 7:29 PM:
---

Can we please create a new bug for this issue with the patches?  The current 
patch was already released.  The new patch should be marked closed in Trinidad 
2.1.1.


was (Author: darkarena):
Can we please create a new bug for this issue with the patchs.  The current 
patch was already released.

 externalize skin repositories by using SkinProvider SPI
 ---

 Key: TRINIDAD-2406
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
 Fix For: 2.1.0-core

 Attachments: er-skin-provider-ver7.patch, 
 er-skin-provider-ver8.patch, fc-to-ec.patch, 
 skin-addition-bug-trinidad.patch, spr-bugfix.patch


 Introduce SkinProvider SPI. Users can use this to create their own skip 
 repositories and expose their skins to the skinning framework.
 Provide an API to query skin using skin family, skin id, render kit - This 
 will make use of the existing SkinFactory APIs. Only change here is that it 
 should go over all the available SkinProvider SPIs to find a match.
 Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or 
 skins defined using trinidad-skins.xml).
 Provide an API to list all the available skins from all SkinProvider SPIs and 
 make the skin metadata thus available.
 Make SkinExtension part of public API so that users can use this class to 
 create the Skin objects which they expose through their SkinProvider SPIs



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

Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-18 Thread Scott O'Bryan

+1
-- 
Scott O'Bryan

On November 18, 2013 at 8:25:37 AM, Max Starets (max.star...@oracle.com) wrote:

+1
On 11/15/2013 4:02 PM, Scott O'Bryan wrote:
Hello everyone,

I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 
which is the latest in the Trinidad render kit series.  This is the first 
release in over a year and contains over a hundred bug fixes since the last 
release.  All Blocker bugs are currently fixed and all patches request by the 
community have been applied.  All tests are passing as is the apache-rat:check.

I have generated the tag [1] and have deployed the build artifacts to nexus 
[2].  I have also included the source archive [3].  Please take a look at the 
Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

Please note: 
This vote is majority approval with a minimum of three +1 votes (see [4]). 

 
[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and 
why.. 
  

Thanks,
  Scott O'Bryan

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
[2] https://repository.apache.org/content/repositories/orgapachemyfaces-141
[3] 
https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes

[VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-15 Thread Scott O'Bryan

Hello everyone,

I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 
which is the latest in the Trinidad render kit series.  This is the first 
release in over a year and contains over a hundred bug fixes since the last 
release.  All Blocker bugs are currently fixed and all patches request by the 
community have been applied.  All tests are passing as is the apache-rat:check.

I have generated the tag [1] and have deployed the build artifacts to nexus 
[2].  I have also included the source archive [3].  Please take a look at the 
Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

Please note: 
This vote is majority approval with a minimum of three +1 votes (see [4]). 

 
[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and 
why.. 
  

Thanks,
  Scott O'Bryan

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
[2] https://repository.apache.org/content/repositories/orgapachemyfaces-141
[3] 
https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes

[VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-15 Thread Scott O'Bryan

Hello everyone,

I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 
which is the latest in the Trinidad render kit series.  This is the first 
release in over a year and contains over a hundred bug fixes since the last 
release.  All Blocker bugs are currently fixed and all patches request by the 
community have been applied.  All tests are passing as is the apache-rat:check.

I have generated the tag [1] and have deployed the build artifacts to nexus 
[2].  I have also included the source archive [3].  Please take a look at the 
Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

Please note: 
This vote is majority approval with a minimum of three +1 votes (see [4]). 

 
[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and 
why.. 
  

Thanks,
  Scott O'Bryan

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
[2] https://repository.apache.org/content/repositories/orgapachemyfaces-141
[3] 
https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-15 Thread Scott O'Bryan

Please ignore..  Sent from the wrong account.  :)
-- 
Scott O'Bryan

On November 15, 2013 at 1:54:20 PM, Scott O'Bryan (scott.obr...@oracle.com) 
wrote:

Hello everyone,

I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 
which is the latest in the Trinidad render kit series.  This is the first 
release in over a year and contains over a hundred bug fixes since the last 
release.  All Blocker bugs are currently fixed and all patches request by the 
community have been applied.  All tests are passing as is the apache-rat:check.

I have generated the tag [1] and have deployed the build artifacts to nexus 
[2].  I have also included the source archive [3].  Please take a look at the 
Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

Please note: 
This vote is majority approval with a minimum of three +1 votes (see [4]). 

 
[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and 
why.. 
  

Thanks,
  Scott O'Bryan

[1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
[2] https://repository.apache.org/content/repositories/orgapachemyfaces-141
[3] 
https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
[4] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] [Resolved] (TRINIDAD-2387) FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds() return immutable when empty


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

Scott O'Bryan resolved TRINIDAD-2387.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

r1541984 | sobryan | 2013-11-14 17:22:31 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/context/PartialViewContextImpl.java

TRINIDAD-2387 - 
FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds() return 
immutable when empty

Made returned map mutable.


 FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds() 
 return immutable when empty
 

 Key: TRINIDAD-2387
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2387
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.1.0-core
 Environment: Windows Vista
Reporter: Clément
Assignee: Scott O'Bryan
Priority: Blocker
 Fix For: 2.1.0-core


 I'm facing an UnsupportedOperationException when trying to add a dynamique 
 Id in RendersIds of partialViewContext 
 (FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds().add(MyCompId);).
 As Balus C said : It appears that 
 FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds() 
 returns Collections#emptySet() when there are no render IDs. This is however 
 immutable! This totally explains the exception you're facing.(...) The 
 javadoc clearly says that the returned collection must be mutable.
 More information here : 
 http://stackoverflow.com/questions/16589553/unsupportedoperationexception-using-ajax-update-or-getrenderids-add
 Clément



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

[jira] [Updated] (TRINIDAD-2422) repo out of sync


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

Scott O'Bryan updated TRINIDAD-2422:


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

Fixed by this revision:

r1537167 | sobryan | 2013-10-30 16:36:38 + | 1 line
Changed paths:
   M /myfaces/trinidad/trunk/pom.xml

Fix the trinidad build.


 repo out of sync
 

 Key: TRINIDAD-2422
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2422
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Gerhard Petracek
Assignee: Scott O'Bryan
Priority: Critical
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2422.patch


 http://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ is out of sync 
 and therefore http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ fails 
 to build



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

[jira] [Resolved] (TRINIDAD-1107) tr:table - scrolling of content


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

Scott O'Bryan resolved TRINIDAD-1107.
-

Resolution: Fixed

r1539892 | sobryan | 2013-11-08 01:03:15 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/TreeTable.xml
   M 
/myfaces/trinidad/trunk/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/CoreTable.xml
   M 
/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/java/org/apache/myfaces/trinidaddemo/table/DynamicModel.java
   M 
/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/components/table_dynamic.jspx
   M 
/myfaces/trinidad/trunk/trinidad-examples/trinidad-demo/src/main/webapp/components/treeTable.jspx
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/desktop/DesktopTableRenderer.java

TRINIDAD-1107 - tr:table - scrolling of content

* Thanks for the patch Cedric


 tr:table - scrolling of content
 ---

 Key: TRINIDAD-1107
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1107
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Gerhard Petracek
Assignee: Scott O'Bryan
 Attachments: scrolltable patch v2.3 - TRUNK.txt, scrolltable patch 
 v2.3 - branch 1.2.x.txt, scrolltable patch v2.4 - TRUNK.txt, scrolltable 
 patch v2.4 - branch 1.2.x.txt


 if a table is too long and it comes to page scrollbars, you cannot see the 
 header all the time (e.g. after scrolling to the bottom of the table).
 so we need a scrollbar for the table body.



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

[jira] [Updated] (TRINIDAD-2418) Add IE11 trinidad agent support


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

Scott O'Bryan updated TRINIDAD-2418:


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

r1529209 | sobryan | 2013-10-04 16:37:42 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/agent/AgentFactoryImpl.java

TRINIDAD-2418 - Add IE11 trinidad agent support

* Thanks for the patch Gary


 Add IE11 trinidad agent support
 ---

 Key: TRINIDAD-2418
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2418
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
 Environment: n/a
Reporter: Gary VanMatre
Assignee: Scott O'Bryan
 Fix For: 2.1.0-core

 Attachments: AgentFactoryImpl.java.patch


 IE11 has changed the user agent string removing the MSIE token. JIRA 
 TRINIDAD-2306 was entered a while back to use the trident version over the 
 MSIE but the MSIE token was still a precondition. 



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

[jira] [Updated] (TRINIDAD-2416) Provide default implementation for getRenderedFacetsAndChildren


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

Scott O'Bryan updated TRINIDAD-2416:


Resolution: Fixed
  Assignee: Blake Sullivan
Status: Resolved  (was: Patch Available)

r1527787 | bsullivan | 2013-09-30 21:07:57 + | 1 line
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponent.java

[Trinidad-2416]Provide default implementation for getRenderedFacetsAndChildren


 Provide default implementation for getRenderedFacetsAndChildren 
 

 Key: TRINIDAD-2416
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2416
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
 Environment: trunk
Reporter: Venkata Guddanti
Assignee: Blake Sullivan
 Attachments: TRINIDAD-2416.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 UIXComponent needs to provide default implementation of 
 getRenderedFacetsAndChildren for cases where a
 UIXComponent subclass wants to restore the default implementation that one of 
 its superclasses have overridden.
 The usecase is as follows: Currently UIXShowDetail short-circuits the 
 processing of its children through getRenderedFacetsAndChildren when it is 
 not disclosed. However its subclasses might want to processes certain facets 
 even when it is not disclosed. In such cases the subclasses can override the 
 getRenderedFacetsAndChildren and fallback to the default implementation which 
 delegates to the renderer 



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

[jira] [Updated] (TRINIDAD-2408) TrPage._getTextContent is not working in IE10


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

Scott O'Bryan updated TRINIDAD-2408:


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

r1526877 | sobryan | 2013-09-27 12:41:01 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/Page.js

TRINIDAD-2408 - TrPage._getTextContent is not working in IE10

* Thanks for the patch Paresh


 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core, 2.1.0-core

 Attachments: 17285610.patch, 17285610_updated.patch, IE10-Test3.zip


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.



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

[jira] [Resolved] (TRINIDAD-2398) add component tracking ability to RequestContext


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

Scott O'Bryan resolved TRINIDAD-2398.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core
 Assignee: Jeanne Waldman

r1524142 | jwaldman | 2013-09-17 17:51:56 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java-templates/org/apache/myfaces/trinidad/component/UIXEditableValueTemplate.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java-templates/org/apache/myfaces/trinidad/component/UIXIteratorTemplate.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/ComponentProcessingContext.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXCollection.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponent.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java

TRINIDAD-2398 add component tracking ability to RequestContext
Thanks to Jing Wu for the patch


 add component tracking ability to RequestContext
 

 Key: TRINIDAD-2398
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2398
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.1-core
 Environment: this is environment independent.
Reporter: Jing Wu
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: JIRA-2398-main-fix.patch, JIRA-2398-main-sept17.patch, 
 JIRA-2398-main.patch

   Original Estimate: 72h
  Remaining Estimate: 72h

 there are cases where we need to know which component is under processing. 
 This can be achieved if we can maintain component stack in RequestContext and 
 provide API to push/pop/peek the component stack.



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

[jira] [Commented] (TRINIDAD-2414) non namespaced selectors are getting compressed with skin compression turned on


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

Scott O'Bryan commented on TRINIDAD-2414:
-

Anand, what is the status of this bug?


 non namespaced selectors are getting compressed with skin compression turned 
 on
 ---

 Key: TRINIDAD-2414
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2414
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Scott O'Bryan
 Attachments: jira-2414.patch


 Selectors such as:
 .AFSelector { ... }
 was getting rendered in both compressed and uncompressed way with compression 
 turned on.
 But this was not happening for
 .AFSelector af|foo { ... }
 af|foo.AFSelector { ... }
 This was rendered as compressed with compression turned on. 
 The solution is to render the non namespaced selectors only in un compressed 
 format.



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

[jira] [Commented] (TRINIDAD-2405) Allow numberConverter to specify roundingmode


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

Scott O'Bryan commented on TRINIDAD-2405:
-

There is a component for this in 2.1.0-core:

r1516604 | gcrawford | 2013-08-22 20:55:56 + | 3 lines
Changed paths:
   M /myfaces/trinidad/trunk/trinidad-api/src/main/resources/trinidad-config.xsd

TRINIDAD-2405 Allow numberConverter to specify roundingmode

thanks to yee-wah


 Allow numberConverter to specify roundingmode
 -

 Key: TRINIDAD-2405
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2405
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Yee-Wah Lee
Assignee: Jeanne Waldman
Priority: Minor
 Fix For: 2.0.8-plugins, 2.1.0-core

 Attachments: TrinPlugin_2405_numberConverterRoundingCode.diff, 
 TrinTrunk_2405_numberConverterRounding.diff, 
 TrinTrunk_2405_numberConverterRounding_xsdfix.diff


 NumberFormat has a method setRoundingMode() which controls how numbers are 
 rounded. The JDK default is RoundingMode.HALF_EVEN. 
 This tracks adding an attribute to the numberConverter so that the rounding 
 mode can be set, instead of always using JDK defaults. 



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

[jira] [Commented] (TRINIDAD-2409) improve diagnostics during tag execution component binding failures


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

Scott O'Bryan commented on TRINIDAD-2409:
-

This was added to 2.1.0-core:

r1515879 | jwaldman | 2013-08-20 17:00:57 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/UIXComponentELTag.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/LoggerBundle.xrts

TRINIDAD-2409  improve diagnostics during tag execution component binding 
failures 
Thanks to Pavitra Subramaniam for the patch


 improve diagnostics during tag execution component binding failures
 ---

 Key: TRINIDAD-2409
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2409
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.1-core
Reporter: Pavitra Subramaniam
 Fix For: 2.1.0-core

 Attachments: jira-2409.patch


 2 places where error reporting can be improved is in 
 1.  UIXComponentELTag.doStartTag()
 We could add a try/catch around the super.doStartTag(), do some severe 
 logging (eg.log a scoped id) in response to exceptions, and re-throw. 
 2.  UIXComponentELTag.createComponent()
 This might be a reasonable place to detect the cases where a component that 
 you pull out of a component binding during createComponent() is already 
 attached to some component tree- and thus the (severe) error is justified.



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

[jira] [Updated] (TRINIDAD-2402) mechanism to setup a new component binding context


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

Scott O'Bryan updated TRINIDAD-2402:


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

 mechanism to setup a new component binding context
 --

 Key: TRINIDAD-2402
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2402
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 2.0.1-core
Reporter: Pavitra Subramaniam
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: trinidad-2402.patch


 There are usecases where a custom tag that provides the ability to load 
 dynamic layouts (or page fragments) based on app flow, requiring that new 
 components be re-created when the tag is executed and a new layout different 
 from the current one needs to be loaded. 
 Merely deleting the component sub-trees in the tag handler does not entirely 
 address the issue because when the tag is re-executed today, if a binding EL 
 is set on the component, then the component instance held by the backing bean 
 instance (typically a reuqest scoped bean) get reused instead of a new 
 component being created.
 In order to force create the component instance, this new API will allow tag 
 handlers to notify the framework by starting a new component binding 
 context. Between a pair of push and pop calls, component bindings will be 
 cleared allowing for new component instances to be created and pushed to the 
 backing bean.
   /**
* Starts a new component binding context. Typically called from tag 
 handlers when component 
* bindings in its subtree needs to be cleared, forcing the creation of new 
 components. 
* 
* @param context FacesContext instance
* @see RequestContext#popComponentBindingContext
* @see RequestContext#isInComponentBindingContext
*/
   public static void pushComponentBindingContext(FacesContext context)  
   {
   }
   /**
* Pops out of the last pushed component binding context. Component binding 
 instances will not be 
* cleared after popping out the outermost context.
* 
* @param context FacesContext instance
* @see RequestContext#pushComponentBindingContext
* @see RequestContext#isInComponentBindingContext
*/
   public static void popComponentBindingContext(FacesContext context)
   {
   }
   /**
* Returns true if we are currently within a component binding context.
* 
* @see RequestContext#pushComponentBindingContext
* @see RequestContext#popComponentBindingContext
*/
   public static boolean isInComponentBindingContext(FacesContext context)
   {
   }



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

[jira] [Resolved] (TRINIDAD-2401) Clean up skinning code to avoid use of obsolete synchronized classes


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

Scott O'Bryan resolved TRINIDAD-2401.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

r1503980 | bsullivan | 2013-07-17 03:00:30 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/cache/FileSystemStyleCache.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/util/CSSGenerationUtils.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/util/NameUtils.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/util/StyleWriterFactory.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/xml/parse/StyleSheetDocument.java

[Trinidad]TRINIDAD-2401 Clean up skinning code to avoid use of obsolete 
synchronized classes

The skinning code currently uses several obsolete implementation class--Vector, 
Stack, HashTable that are implicitly synchronized. None of this synchronization 
is necessary. Replaces these classes with their modern equivalents. In 
addition, much of the code is confusing due to functions performing multiple 
different tasks simultaneously. Break these up into easy to understand pieces 
that perform a single task.


 Clean up skinning code to avoid use of obsolete synchronized classes
 

 Key: TRINIDAD-2401
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2401
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Blake Sullivan
Assignee: Blake Sullivan
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: jira2401_main.diff

   Original Estimate: 72h
  Remaining Estimate: 72h

 The skinning code currently uses several obsolete implementation 
 class--Vector, Stack, HashTable that are implicitly synchronized.  None of 
 this synchronization is necessary.  Replaces these classes with their modern 
 equivalents.  In addition, much of the code is confusing due to functions 
 performing multiple different tasks simultaneously.  Break these up into easy 
 to understand pieces that perform a single task.



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

[jira] [Updated] (TRINIDAD-2383) issue with table stamp state


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

Scott O'Bryan updated TRINIDAD-2383:


Resolution: Fixed
  Assignee: Jeanne Waldman
Status: Resolved  (was: Patch Available)

r1487973 | jwaldman | 2013-05-30 18:55:33 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/StampState.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXCollection.java

TRINIDAD-2383 issue with table stamp state 
thanks to Jing Wu for the patch


 issue with table stamp state
 

 Key: TRINIDAD-2383
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2383
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.1-core
 Environment: This issue is environment independent.
Reporter: Jing Wu
Assignee: Jeanne Waldman
 Attachments: stampstate-16632043-main.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 A component's stamp state contains 3 parts: the stamp state of itself, the 
 stamp state of its children (if there's any), the stamp state of its facets 
 (if there's any). We use array to store stamp state of its children, and 
 facets. But if somehow between stamp saving and restoring, the child 
 components are changed in position, we would run into classcastexception 
 since we expect one component but encounter a different one. 



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

[jira] [Updated] (TRINIDAD-2389) review and fix values for @platform in skinning documentation


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

Scott O'Bryan updated TRINIDAD-2389:


Resolution: Fixed
  Assignee: Jeanne Waldman
Status: Resolved  (was: Patch Available)

r1485788 | jwaldman | 2013-05-23 17:55:16 + | 2 lines
Changed paths:
   M /myfaces/trinidad/trunk/src/site/xdoc/devguide/skinning.xml

TRINIDAD-2389  review and fix values for @platform in skinning documentation
thanks to Anand V Nath for the patch


 review and fix values for @platform in skinning documentation
 -

 Key: TRINIDAD-2389
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2389
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Jeanne Waldman
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: jira-2389.patch


 This bug is for reviewing and fixing the valid values for @platform mentioned 
 in the skinning documentation: 
 http://myfaces.apache.org/trinidad/devguide/skinning.html



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

[jira] [Commented] (TRINIDAD-2391) Enhancements to allow for custom FileUpload code


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

Scott O'Bryan commented on TRINIDAD-2391:
-

r1485058 | sobryan | 2013-05-22 04:04:36 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/RequestContextFactory.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/ChainedUploadedFileProcessor.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/FileUploadConfiguratorImpl.java
   A 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/FileUploadUtils.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFiles.java

TRINIDAD-2391: Enhancements to allow for custom FileUpload code


 Enhancements to allow for custom FileUpload code
 

 Key: TRINIDAD-2391
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2391
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core


 The FileUpload code in Trinidad is handled through a configurator. This 
 system expects to be the only system to process file uploads and is a 
 relatively closed system.  Some enhancements should be made to the internal 
 implementation of the file upload code that could allow extensions to 
 implement some custom logic for handling uploaded files and allow them to be 
 plugged into the FileUpload framework. 



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

[jira] [Resolved] (TRINIDAD-2385) trinidad-config documentation wrong for time-zone parameter defaulting


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

Scott O'Bryan resolved TRINIDAD-2385.
-

Resolution: Fixed

r1483020 | jwaldman | 2013-05-15 19:19:45 + | 2 lines
Changed paths:
   M /myfaces/trinidad/trunk/src/site/xdoc/devguide/configuration.xml

TRINIDAD-2385 trinidad-config documentation wrong for time-zone parameter 
defaulting 
Thanks to Yee-Wah Lee for the patch


 trinidad-config documentation wrong for time-zone parameter defaulting
 --

 Key: TRINIDAD-2385
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2385
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Yee-Wah Lee
Assignee: Jeanne Waldman
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: trunk_2385_timezoneConfigDoc.diff


 The documentation for time-zone defaulting in this link is incorrect:
 http://myfaces.apache.org/trinidad/devguide/configuration.html#trinidad-config.xml
 The code does not attempt to guess the user's timezone. Instead, it defaults
 to the value returned by JDK TimeZone.getDefault



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

[jira] [Resolved] (TRINIDAD-2381) Add header tags h1..h6 support to XhtmlFormattedText


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

Scott O'Bryan resolved TRINIDAD-2381.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core
 Assignee: Jeanne Waldman

r1478551 | jwaldman | 2013-05-02 21:10:02 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/XhtmlFormattedText.java

TRINIDAD-2381 Add header tags h1..h6 support to XhtmlFormattedText 
Thanks to Yee-Wah Lee for the patch


 Add header tags h1..h6 support to XhtmlFormattedText
 

 Key: TRINIDAD-2381
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2381
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Reporter: Yee-Wah Lee
Assignee: Jeanne Waldman
Priority: Minor
 Fix For: 2.1.0-core

 Attachments: trunk_2381_XhtmlFormattedTextAndHeaders.diff


 Allow components which use the XhtmlFormattedText (e.g. outputFormatted) to 
 support the HTML header tags h1..h6



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

[jira] [Resolved] (TRINIDAD-2378) UIXComponentBase should override clearCachedClientId to avoid calling getId() at times when the UIViewRoot isn't present


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

Scott O'Bryan resolved TRINIDAD-2378.
-

Resolution: Fixed

r1470258 | bsullivan | 2013-04-21 03:25:49 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponent.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/test/java/org/apache/myfaces/trinidad/component/ClientIdCachingTest.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/test/java/org/apache/myfaces/trinidad/render/RenderUtilsTest.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/renderkit/CoreRenderKitTest.java

[TRINIDAD-2378] UIXComponentBase should override clearCachedClientId to avoid 
calling getId() at times when the UIViewRoot isn't present

The current implementation of clearCachedClientIds on UIXComponent is final and 
always calls setId() with the result of getId(). The problem is that calling 
getId() requires a call to UIViewRoot.getUniqueId() if the component does not 
already have an id. Unfortunately, there are times when the UIViewRoot isn't 
attached to the FacesContext when we need to clear cached client ids. The 
easiest and fastest solution is to make clearCachedClientIds() non-final and 
allow UIXComponentBase to override the method to clear out its cached clientId 
directly.


 UIXComponentBase should override clearCachedClientId to avoid calling getId() 
 at times when the UIViewRoot isn't present
 

 Key: TRINIDAD-2378
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2378
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Blake Sullivan
Assignee: Blake Sullivan
 Attachments: trin2378.diff

   Original Estimate: 4h
  Remaining Estimate: 4h

 The current implementation of clearCachedClientIds on UIXComponent is final 
 and always calls setId() with the result of getId().  The problem is that 
 calling getId() requires a call to UIViewRoot.getUniqueId() if the component 
 does not already have an id.  Unfortunately, there are times when the 
 UIViewRoot isn't attached to the FacesContext when we need to clear cached 
 client ids.  The easiest and fastest solution is to make 
 clearCachedClientIds() non-final and allow UIXComponentBase to override the 
 method to clear out its cached clientId directly.



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

[jira] [Updated] (TRINIDAD-2377) surrogate characters in outputFormatted throws IllegalArgumentException


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

Scott O'Bryan updated TRINIDAD-2377:


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

r1468529 | jwaldman | 2013-04-16 17:51:12 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/HTMLEscapes.java

TRINIDAD-2377 surrogate characters in outputFormatted throws 
IllegalArgumentException
reviewed by Blake Sullivan and Yushui Du


 surrogate characters in outputFormatted throws IllegalArgumentException
 ---

 Key: TRINIDAD-2377
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2377
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-SurrogateOutputFormattedPatch.patch


 af:outputFormatted value=#{TestInput.surrogateVal} id=of1/ 
 where
 TestInput.surrogateValue is a surrogateValue, like
   private String surrogateVal = \ud840\udc00;
   public void setSurrogateVal(String surrogateVal) {
   this.surrogateVal = surrogateVal;
   }
   public String getSurrogateVal() {
   return surrogateVal;
 The page shows up blank, and you get an IllegalArgumentException from 
 HTMLEscapes. outputText works fine. This is a regression caused by 
 MYFACES-3690 Trinidad doesn't support surrogate characters



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

[jira] [Resolved] (TRINIDAD-2420) Trinidad doesn't support surrogate characters


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

Scott O'Bryan resolved TRINIDAD-2420.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

r1443711 | jwaldman | 2013-02-07 20:39:17 + | 1 line
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/HTMLEscapes.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XMLEscapes.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/xrts/org/apache/myfaces/trinidadinternal/resource/LoggerBundle.xrts

MYFACES-3690 Trinidad doesn't support surrogate characters


 Trinidad doesn't support surrogate characters
 -

 Key: TRINIDAD-2420
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2420
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: surrogateCharBug.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 [Problem Description:]
 Create a simple jsf page as below:
 tr:inputText label=Label 1 id=it1/
 tr:commandButton text=commandButton 1 id=cb1/
 In IE7, when we enter a surrogate character, then click submit button,
 surrogate character can be correctly displayed when page rendered.
 While in FF3, the surrogate character are displayed as 2 characters after
 clicked the submit button.
 NOTE: If using pre 7 jetty, the surrogate char will disappear (bug in jetty). 
 I had to use JDeveloper to reproduce.
 [Test Data:]
 You can copy a sample surrogate character from:
 http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%F0%A0%80%80
 Note: You must install surrogate font in your env to display the surrogate
 characters.
 [Analysis:]
 Check the html source of generated page, the surrogate character is written
 into 2 decimal value '#55360;#56320;', and Firefox can't recognize these 2
 Decimal value as a single surrogate character.
 While in IE, it can recognize these 2 decimal value represent a single
 surrogate character.
 According to
 http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=%F0%A0%80%80, the 
 decimal value for this surrogate character is 131072, if in html source code,
 we write #131072; instead of '#55360;#56320;', the surrogate character
 can display well in both IE7 and FF3.
 Fix:
 The fix is to HTMLEscapes and XMLEscapes. if char is high-surrogate, use 
 Character.getCodePoint and encode that.



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

[jira] [Updated] (TRINIDAD-2358) add features support in the trinidad-skins to the skin-addition node


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

Scott O'Bryan updated TRINIDAD-2358:


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

r1442351 | jwaldman | 2013-02-04 20:57:29 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/skin/SkinAddition.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinExtension.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinUtils.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/skin/parse/SkinAdditionNode.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/skin/parse/SkinAdditionNodeParser.java
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/resources/org/apache/myfaces/trinidadinternal/ui/laf/xml/schemas/skin/trinidad-skins.xsd

TRINIDAD-2358 add features support in the trinidad-skins to the 
skin-addition node
thanks to Gary VanMatre for the patch


 add features support in the trinidad-skins to the skin-addition node
 

 Key: TRINIDAD-2358
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2358
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.1-core
 Environment: generic
Reporter: Gary VanMatre
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: features-in-skin-additions.patch


 JIRA TRINIDAD-2270 added an enhancement to the trinidad-skins.xml to add 
 features to a skin definition that could be used at runtime to conditionally 
 enable rendering behavior.  The proposed improvement is to extend the 
 features support to skin-addtion so that custom components that add to an 
 existing skin can also use the runtime features metadata.



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

[jira] [Commented] (TRINIDAD-2347) JSESSIONID is not send with the first response


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

Scott O'Bryan commented on TRINIDAD-2347:
-

r1438122 | mstarets | 2013-01-24 18:38:05 + | 1 line
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/application/ViewDeclarationLanguageFactoryImpl.java

TRINIDAD-2347 - JSESSIONID is not send with the first response


 JSESSIONID is not send with the first response
 --

 Key: TRINIDAD-2347
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2347
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Facelets
Affects Versions: 2.0.1-core
Reporter: Max Starets
Assignee: Max Starets
 Fix For: 2.1.0-core


 To reproduce the issue, create a Facelets page with a form producing fairly 
 large (~50K) HTML content. Notice that the response for the initial GET does 
 not send JSESSIONID to the client. This is happening because the session is 
 'touched' by the state saving code after the response headers have been 
 committed to the client.
 The fix would be to 'touch' the session before rendering begins



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

[jira] [Updated] (TRINIDAD-2341) Incorrect assert expression in FileUploadConfiguratorImpl


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

Scott O'Bryan updated TRINIDAD-2341:


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

r1411883 | gcrawford | 2012-11-20 21:20:28 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/FileUploadConfiguratorImpl.java

TRINIDAD-2341 Incorrect assert expression in FileUploadConfiguratorImpl 

Thanks to Kentaro


 Incorrect assert expression in FileUploadConfiguratorImpl
 -

 Key: TRINIDAD-2341
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2341
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Kentaro Kinebuchi
Assignee: Gabrielle Crawford
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2341.patch


 Test the inputFile component in an environment with debugging enabled so that 
 assertions are enabled. Notice that you cannot upload a file and an assertion 
 is thrown from Line 477:
 assert(properties == null);
 The expression is incorrect, it should be:
 assert(properties != null);



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

[jira] [Updated] (TRINIDAD-2316) Add support for adding a properties Map to UploadedFile


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

Scott O'Bryan updated TRINIDAD-2316:


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

r1395779 | jwaldman | 2012-10-08 21:07:37 + | 3 lines
Changed paths:
   A 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/ui/marshal
   A 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/ui/marshal/MarshalingService.java

TRINIDAD-2316 Add support for adding a properties Map to UploadedFile 
I forgot to add the new file, MarshalingService.java. It was in the patch.
Thanks to Kentaro Kinebuchi for the patch


 Add support for adding a properties Map to UploadedFile
 ---

 Key: TRINIDAD-2316
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2316
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Kentaro Kinebuchi
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: Trinidad-2316.patch


 This enhancement is so that arbritrary properties can be specified for 
 uploaded files. For example, a description field can be specified for a file. 
 Support should be added for returning a map of properties from the 
 UploadedFile object. Rather than adding new methods to the UploadedFile 
 interface and breaking backward compatibility, the proposal is to create a 
 new abstract class called AbstractUploadedFile with a getProperties() method 
 which returns MapString, Object and have UploadedFileImpl extend this 
 class. Any consumers of UploadedFiles can then check for if it extends this 
 abstract class to see if properties are available. Also, custom file 
 processors will need to return UploadedFile instances which extend 
 AbstractUploadedFile if they need to have the framework add properties.
 The file properties will be submitted together with the file as a parameter 
 on the form and the value will be marshalled into XML. 



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

[jira] [Updated] (TRINIDAD-2326) Don't permanently cache the null resource loader


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

Scott O'Bryan updated TRINIDAD-2326:


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

r1394135 | jwaldman | 2012-10-04 16:21:59 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/ResourceServlet.java
   D 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/TempDirectoryResourceLoader.java

TRINIDAD-2326 Don't permanently cache the null resource loader 
Thanks to Mark Yvanovich for the patch


 Don't permanently cache the null resource loader
 

 Key: TRINIDAD-2326
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2326
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions:  1.2.12-core, 2.0.1-core, 2.1.0-core
Reporter: Mark Yvanovich
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: jira2326-2.0.0.x.patch, jira2326-trunk.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 In ResourceServlet._getResourceLoader(), if an exception occurs while getting 
 the resource loader, we use the null resource loader and this loader is 
 cached so from that point on we return null for any resource request with the 
 specified servlet path that caused the exception.  We want to make this a bit 
 more fault tolerant so we are going to implement a exponential backoff 
 resource loader to be used in place of the null resource loader.  This loader 
 will periodically re-attempt to load the resource loader for the specified 
 servlet path and replace the exponential backoff resource loader in 
 ResourceServlet's loader cache if it is found so that subsequent requests 
 will succeed.



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

[jira] [Updated] (TRINIDAD-2324) File uploads are very slow


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

Scott O'Bryan updated TRINIDAD-2324:


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

r1394279 | jwaldman | 2012-10-04 21:36:15 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/share/util/MultipartFormHandler.java

TRINIDAD-2324 File uploads are very slow
using BufferedInputStream and some changes in _readline (make variable final).
Thanks to Kentaro Kinebuchi for the patch


 File uploads are very slow
 --

 Key: TRINIDAD-2324
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2324
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.2-core
Reporter: Kentaro Kinebuchi
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2324.patch


 File uploads using the Trinidad File Upload Framework are very slow with 
 uploads typically taking several minutes for files on the order of 100MB. It 
 is substantially slower than FTPing an equivalent file.
 After profiling the application, most of the sloweness is from inefficiencies 
 in MultipartFormHandler.java.
 After making a few changes to the method _readline() and also using a 
 BufferedInputStream, the performance was doubled.



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

[jira] [Updated] (TRINIDAD-2294) AFLogo selector uses a 'relative url' notation when a 'context relative url' is more desirable.


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

Scott O'Bryan updated TRINIDAD-2294:


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

r1388284 | jwaldman | 2012-09-21 00:53:07 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/resources/META-INF/adf/styles/simple-desktop.css

TRINIDAD-2294 AFLogo selector uses a 'relative url' notation when a 'context 
relative url' is more desirable. 
thanks to Pavitra Subramaniam for the patch


 AFLogo selector uses a 'relative url' notation when a 'context relative url' 
 is more desirable.
 ---

 Key: TRINIDAD-2294
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2294
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions:  1.2.12-core, 2.0.1-core
Reporter: Pavitra Subramaniam
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: simple-desktop.xss.patch, trunk-simple-desktop.css.patch


 The skin selector - .AFLogo - defined in simple-desktop.xss defines the 
 property 'background-image' using a relative url notation, as follows
   style selector=.AFLogo
 property 
 name=background-imageurl('../../images/logo-dark.png')/property
 The above usage runs into problems when images along with other resources get 
 hosted on a CDN for example. It's desirable in this case to use a context 
 relative url (as explained here - 
 http://myfaces.apache.org/trinidad/devguide/skinning.html#urls)



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

[jira] [Updated] (TRINIDAD-2305) Add a new Trinidad UIXListView component


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

Scott O'Bryan updated TRINIDAD-2305:


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

r1378359 | mstarets | 2012-08-28 21:43:57 + | 1 line
Changed paths:
   A 
/myfaces/trinidad/trunk/trinidad-api/src/main/java-templates/org/apache/myfaces/trinidad/component/UIXListViewTemplate.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/LoggerBundle.xrts
   A 
/myfaces/trinidad/trunk/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/ListView.xml

TRINIDAD-2305 - Add a new Trinidad UIXListView component. Thanks, Venkata 
Guddanti, for the patch


 Add a new Trinidad UIXListView component 
 -

 Key: TRINIDAD-2305
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2305
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Venkata Guddanti
Assignee: Max Starets
 Fix For: 2.1.0-core

 Attachments: UIXListView.patch

   Original Estimate: 72h
  Remaining Estimate: 72h

 Add a new trinidad component UIXListView. 



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

[jira] [Updated] (TRINIDAD-2370) problem with using column index to access stamping state


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

Scott O'Bryan updated TRINIDAD-2370:


Status: Patch Available  (was: Open)

 problem with using column index to access stamping state
 

 Key: TRINIDAD-2370
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2370
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.1-core
 Environment: this is environment generic
Reporter: Jing Wu
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2370.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 the stamp state is accessed with dual key (currency + column index), but 
 using index is not reliable. If column index is ever changed, a wrong stamp 
 state is retrieved and this causes issues.



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

[jira] [Updated] (TRINIDAD-2290) Need to log the exception in each catch block of ResourceServlet._getResourceLoader()


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

Scott O'Bryan updated TRINIDAD-2290:


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

r1368107 | jwaldman | 2012-08-01 16:38:20 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/ResourceServlet.java

TRINIDAD-2290 Need to log the exception in each catch block of 
ResourceServlet._getResourceLoader()
commit version 2 patch. This removes the logging for the catch block 
(NoSuchMethodException) that is the expected default path. 
thanks to Mark Yvanovich for the patch.


 Need to log the exception in each catch block of 
 ResourceServlet._getResourceLoader()
 -

 Key: TRINIDAD-2290
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2290
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Infrastructure
Affects Versions:  1.2.12-core, 2.0.0-core
Reporter: Mark Yvanovich
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: jira2290-trunk-v2.patch, jira2290-trunk.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 We are currently silently ignoring the exceptions that occur when looking up 
 the class loaders in ResourceServlet_getResourceLoader().  We need to log the 
 exception and also log the cause if there is one so that we get a good stack 
 trace of the actual source of the exception.



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

[jira] [Updated] (TRINIDAD-2370) problem with using column index to access stamping state


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

Scott O'Bryan updated TRINIDAD-2370:


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

r1368201 | sobryan | 2012-08-01 19:16:56 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/skin/SkinUtils.java

TRINIDAD-2270 - Add skin configuration item for selective rendering features 
(part duex)

* Thanks for the patch Jeremy


 problem with using column index to access stamping state
 

 Key: TRINIDAD-2370
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2370
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.1-core
 Environment: this is environment generic
Reporter: Jing Wu
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2370.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 the stamp state is accessed with dual key (currency + column index), but 
 using index is not reliable. If column index is ever changed, a wrong stamp 
 state is retrieved and this causes issues.



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

[jira] [Updated] (TRINIDAD-2268) -tr-property-ref replacement needs to work with gradient settings


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

Scott O'Bryan updated TRINIDAD-2268:


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

r1359778 | jwaldman | 2012-07-10 16:53:21 + | 3 lines
Changed paths:
   D 
/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/style/xml/parse/IncludeCompactPropertyNode.java

TRINIDAD-2268 -tr-property-ref replacement needs to work with gradient settings
This commit removes the class IncludeCompactPropertyNode
thanks to Prakash Udupa for the patch


 -tr-property-ref replacement needs to work with gradient settings
 -

 Key: TRINIDAD-2268
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2268
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions:  1.2.12-core
 Environment: This is needed in 1.2.12.6.2 and other current versions
Reporter: Dave Robinson
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: TRINIDAD-2268_over_trunk.patch, 
 TRINIDAD-2268_over_trunk_part2.patch


 We need to be able to use -tr-property-ref to do color replacements for color 
 gradient assignments, like the following (showing examples for all browsers):
   background: linear-gradient(top, #cce2f6 0%, #b1d2f2 100%); 
 background: -moz-linear-gradient(top, #cce2f6 0%, #b1d2f2 100%);
 background: -webkit-gradient(linear, left top, left bottom, 
 color-stop(0%,#cce2f6), color-stop(100%,#b1d2f2));
 background: -webkit-linear-gradient(top, #cce2f6 0%, #b1d2f2 100%);
 filter: 
 progid:DXImageTransform.Microsoft.gradient(startColorstr='#cce2f6', 
 endColorstr='#b1d2f2',GradientType=0 );
 background: -ms-linear-gradient(top, #cce2f6 0%, #b1d2f2 100%);



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

[jira] [Updated] (TRINIDAD-2257) When a resource fails to load, add an exception if the cached temp directory doesn't match the current temp directory


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

Scott O'Bryan updated TRINIDAD-2257:


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

r1328130 | jwaldman | 2012-04-19 22:13:28 + | 2 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/resource/DirectoryResourceLoader.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/ResourceServlet.java
   A 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/webapp/TempDirectoryResourceLoader.java
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/LoggerBundle.xrts

TRINIDAD-2257 When a resource fails to load, add an exception if the cached 
temp directory doesn't match the current temp directory
thanks to Mark Yvanovich for the patch


 When a resource fails to load, add an exception if the cached temp directory 
 doesn't match the current temp directory
 -

 Key: TRINIDAD-2257
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2257
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Reporter: Mark Yvanovich
Assignee: Jeanne Waldman
 Fix For: 2.1.0-core

 Attachments: Jira2257.1.2.12.6.2.patch, 
 TempDirectoryResourceLoader.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 We have been seeing issues periodically where resources are failing to load.  
 Based on debugging information, it seems that this may be a case where the 
 temp directory that is initially cached by the DirectoryResourceLoader is now 
 different from the the current temp directory of the ServletContext object.  
 Create a new package-private class TempDirectoryResourceLoader that extends 
 DirectoryResourceLoader and will throw a state exception if on resouce load 
 failure the temp directories don't match.



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

[jira] [Updated] (TRINIDAD-2260) tr:inputListOfValues - no ReturnEvent is fired when using facelets


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

Scott O'Bryan updated TRINIDAD-2260:


Status: Open  (was: Patch Available)

 tr:inputListOfValues - no ReturnEvent is fired when using facelets
 --

 Key: TRINIDAD-2260
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2260
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Facelets
Affects Versions: 2.0.1-core
 Environment: mojarra 2.0.9
Reporter: Daniel Charczynski
Priority: Critical
 Fix For: 2.0.2-core

 Attachments: error.png


 no ReturnEvent is fired when using facelets
 1. configure launchDialog.xhtml from trinidad-examples as described in 
 TRINIDAD-2259 issue
 2. add 
 tr:inputListOfValues  action=#{launchDialog.doLaunch}  
   windowWidth=600 windowHeight=400 
 returnListener=#{launchDialog.returned}
   
  /
 3. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml 
 4. click on tr:inputListOfValues  icon component - when you close popup 
 window ReturnEvent should be fired but it isn't



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

[jira] [Resolved] (TRINIDAD-2260) tr:inputListOfValues - no ReturnEvent is fired when using facelets


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

Scott O'Bryan resolved TRINIDAD-2260.
-

Resolution: Duplicate
  Assignee: Scott O'Bryan

 tr:inputListOfValues - no ReturnEvent is fired when using facelets
 --

 Key: TRINIDAD-2260
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2260
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Facelets
Affects Versions: 2.0.1-core
 Environment: mojarra 2.0.9
Reporter: Daniel Charczynski
Assignee: Scott O'Bryan
Priority: Critical
 Fix For: 2.0.2-core

 Attachments: error.png


 no ReturnEvent is fired when using facelets
 1. configure launchDialog.xhtml from trinidad-examples as described in 
 TRINIDAD-2259 issue
 2. add 
 tr:inputListOfValues  action=#{launchDialog.doLaunch}  
   windowWidth=600 windowHeight=400 
 returnListener=#{launchDialog.returned}
   
  /
 3. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml 
 4. click on tr:inputListOfValues  icon component - when you close popup 
 window ReturnEvent should be fired but it isn't



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

[ANNOUNCE] Release of Apache MyFaces Trinidad Plugins 2.0.8

2013-11-07 Thread Scott O'Bryan

The Apache MyFaces community is pleased to announce the release of the Apache 
MyFaces Trinidad Plugins 2.0.8.  The MyFaces Trinidad Plugins are a set of 
Maven2 plugins needed to generate the Trinidad Renderkit.  This release is a 
prerequisite to a release of the Trinidad Core.

These Maven2 plugins have been deployed to the Apache Maven2 central repository 
and should be mirrored on ibilio as well.  They are able to be built manually 
using the source in Subversion[1] or via the Source Archive[2].

You may also consult the Release Notes [3] for what's included in this release.

Thanks!
Scott O'Bryan

[1] 
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8
[2] 
https://repository.apache.org/content/groups/public/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip
[3] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290

Re: [TRINIDAD] JIRA tickets for next Trinidad release

2013-11-07 Thread Scott O'Bryan

Any other patches?

-- 
Scott O'Bryan

On November 5, 2013 at 11:12:21 AM, Scott O'Bryan (darkar...@gmail.com) wrote:

Thanks Cédric, I'll add it to the list and try to get to it soon.  Just to 
confirm, these all are going to go into Trinidad 2.1, not 2.0.

-- 
Scott O'Bryan

On November 5, 2013 at 7:40:20 AM, Cédric Durmont (cdurm...@gmail.com) wrote:

Hi Scott,

As a Trinidad user, I apply the patches for these issues and compile my own 
version of Trinidad, so, it would be nice if you could commit those :
TRINIDAD-2211 StateUtils$Saver illegally accessing private 
UIXComponentBase$ComponentSystemEventListenerWrapper
TRINIDAD-2216 The partialSubmit does not work with JSF 2 RI (okay this one 
seems to be in 2.1.x, but not in the stable 2.0.x branch)
TRINIDAD-1107 scrolling of content

Thanks
Cedric Durmont


2013/11/5 Scott O'Bryan darkar...@gmail.com
Okay everyone, while the vote for Trinidad Maven Plugins is underway, I would 
like to know which uncommitted JIRA tickets need to be in this release.  My 
goal is to begin the Trinidad release just after the plugins are released, so 
please reply promptly if you need a patch committed for the next release.

Thanks,
Scott O'Bryan

[jira] [Resolved] (TRINIDAD-2211) StateUtils$Saver illegally accessing private UIXComponentBase$ComponentSystemEventListenerWrapper

2013-11-07 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2211.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

r1539861 | sobryan | 2013-11-07 23:28:33 + | 3 lines
Changed paths:
   M 
/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java

TRINIDAD-2211 - StateUtils$Saver illegally accessing private 
UIXComponentBase$ComponentSystemEventListenerWrapper

* Thanks for the patch Gary VanMatre


 StateUtils$Saver illegally accessing private 
 UIXComponentBase$ComponentSystemEventListenerWrapper
 -

 Key: TRINIDAD-2211
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2211
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.1-core
 Environment: tomcat 6.0.20, myfaces 2.0.11, java 1.6.30, 
 trinidad-api-2.0.1-20110916.225506-35.jar
 , trinidad-impl-2.0.1-20110916.225919-32.jar
Reporter: Caius Gran
Assignee: Scott O'Bryan
 Fix For: 2.1.0-core

 Attachments: Bug2211.java, UIXComponentBase.patch, 
 bug_reproduce_TRINIDAD-2211.jspx, bug_reproduce_TRINIDAD-2211_2.jspx


 The following error appears when clicking an immediate navigation item on 
 navigation pane:
 java.lang.IllegalAccessException: Class 
 org.apache.myfaces.trinidad.bean.util.StateUtils$Saver can not access a 
 member of class 
 org.apache.myfaces.trinidad.component.UIXComponentBase$ComponentSystemEventListenerWrapper
  with modifiers public
   at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
   at java.lang.Class.newInstance0(Class.java:349)
   at java.lang.Class.newInstance(Class.java:308)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils$Saver.restoreState(StateUtils.java:576)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils$SHSaver.restoreState(StateUtils.java:605)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils.restoreStateHolder(StateUtils.java:454)
   at 
 org.apache.myfaces.trinidad.bean.AttachedObjects.restoreState(AttachedObjects.java:262)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils$SHSaver.restoreState(StateUtils.java:607)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils.restoreStateHolder(StateUtils.java:454)
   at 
 org.apache.myfaces.trinidad.bean.PropertyKey.restoreValue(PropertyKey.java:322)
   at 
 org.apache.myfaces.trinidad.bean.util.StateUtils.restoreState(StateUtils.java:400)
   at 
 org.apache.myfaces.trinidad.bean.util.FlaggedPropertyMap.restoreState(FlaggedPropertyMap.java:212)
   at 
 org.apache.myfaces.trinidad.bean.FacesBeanImpl.restoreState(FacesBeanImpl.java:363)
   at 
 org.apache.myfaces.trinidad.component.UIXFacesBeanImpl.restoreState(UIXFacesBeanImpl.java:151)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.restoreState(UIXComponentBase.java:1152)
   at 
 org.apache.myfaces.trinidad.component.UIXCollection.restoreState(UIXCollection.java:369)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:57)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.UIXCollection.processRestoreState(UIXCollection.java:827)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.UIXCollection.processRestoreState(UIXCollection.java:827)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090)
   at 
 org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
   at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:1090

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Scott O'Bryan

Andy, 

Yeah, I was seeing this too.  I was trying to track this as part of my work for 
the next Trinidad release, but I think your right.  This may be handled better 
in the plugin.  At the very least we should evaluate it.  What's happening here 
is a new check was added to test if a class for an attribute happens to be an 
enumeration.  In the case where we get the error, DateListProvider hasn't been 
built yet since the plugins generate the source BEFORE the plugins are built.

I'm going to generate a JIRA ticket and I for one think we need to fix this 
issue before releasing the plugins.  As such. my vote is a -1 pending this 
issue.
-- 
Scott O'Bryan

On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) 
wrote:

Hey Scott -

I attempted to do a clean Trinidad build against the new plugins.  I happened 
to notice this exception during the build:

 [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ 
 trinidad-impl ---
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.DateListProvider
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProvider
     at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:169)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
     at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
     at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
     at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
     at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
     at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
     at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
     at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
     at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 [INFO] Generated 145 JSP tag(s)

I have no idea whether this exception in new in 2.0.8.  Is this something that 
we should look at before rolling out the plugins release?

Andy



On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote:
I was running the tasks needed to release the Trinidad Maven Plugins version 
2.0.8 which is needed as a prerequisite to a Trinidad release.  I have compiled 
the Release Notes[1] for the 2.0.8 release.  

I have generated the tag [2] and have deployed the built artifacts to nexus

[jira] [Created] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code

2013-11-06 Thread Scott O'Bryan (JIRA)

Scott O'Bryan created TRINIDAD-2425:
---

 Summary: New plugins issue a warning on unavailability of 
uncompiled code
 Key: TRINIDAD-2425
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 2.0.8-plugins
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Blocker


The current 2.0.8 tag candidate tries to reference an object to determine type 
while attempting to generate tags.  If this class is in the module where the 
tags are being generated, this can cause a ClassNotFoundException.

This error is being generated multiple times while running a Trinidad Build:
[INFO] ClassNotFound error resolving type 
org.apache.myfaces.trinidad.model.Date 
ListProvider 
java.lang.ClassNotFoundException: 
org.apache.myfaces.trinidad.model.DateListProv 
ider 
at java.net.URLClassLoader$1.run(URLClassLoader.java:202) 
at java.security.AccessController.doPrivileged(Native Method) 
at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:307) 
at 
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL 
oader.java:195) 
at 
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
m.java:255) 
at 
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
m.java:274) 
at 
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. 
java:214) 
at java.lang.ClassLoader.loadClass(ClassLoader.java:248) 
at java.lang.Class.forName0(Native Method) 
at java.lang.Class.forName(Class.java:169) 
at 
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 
ctTagGenerator.resolveType(AbstractTagGenerator.java:247) 
at 
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid 
adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96 
) 
at 
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 

We need to handle this accordingly



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

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Scott O'Bryan

I'm changing my vote to +1.  I was able to fix this issue in the trinidad poms 
by adding:

        dependencies
          dependency
            groupIdorg.apache.myfaces.trinidad/groupId
            artifactIdtrinidad-api/artifactId
            version${project.version}/version
           /dependency
         /dependencies

To the maven-faces plugin definition in trinidad-impl.  So  I'll handle the 
ticket under trinidad and make sure its part of the next release.  The key was 
found in the maven class loading guide:

http://maven.apache.org/guides/mini/guide-maven-classloading.html

I noticed that the error was being issued in the impl package which should have 
had access to the api.  But the dependencies are only explicitly available to 
the javacc plugin or can be referenced manually by the mojo.  Our mojo doesn't 
handle dependencies, so the configuration is necessary.  Might be nice to add 
it at some point though.

Andy, does this work for you?

-- 
Scott O'Bryan

On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:

Andy, 

Yeah, I was seeing this too.  I was trying to track this as part of my work for 
the next Trinidad release, but I think your right.  This may be handled better 
in the plugin.  At the very least we should evaluate it.  What's happening here 
is a new check was added to test if a class for an attribute happens to be an 
enumeration.  In the case where we get the error, DateListProvider hasn't been 
built yet since the plugins generate the source BEFORE the plugins are built.

I'm going to generate a JIRA ticket and I for one think we need to fix this 
issue before releasing the plugins.  As such. my vote is a -1 pending this 
issue.
-- 
Scott O'Bryan

On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) 
wrote:

Hey Scott -

I attempted to do a clean Trinidad build against the new plugins.  I happened 
to notice this exception during the build:

 [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ 
 trinidad-impl ---
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.DateListProvider
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProvider
     at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:169)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
     at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
     at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
     at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
     at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
     at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at 
 sun.reflect.NativeMethodAccessorImpl.invoke

[jira] [Commented] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code

2013-11-06 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2425:
-

I actually found a solution to this by editing the pom of trinidad.  Our 
plugins are not aware of the project dependencies.  Until that code is written, 
we need to add a dependency list when defining the plugin.  I'll handle this as 
a Trinidad bug.

 New plugins issue a warning on unavailability of uncompiled code
 

 Key: TRINIDAD-2425
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 2.0.8-plugins
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Blocker
   Original Estimate: 24h
  Remaining Estimate: 24h

 The current 2.0.8 tag candidate tries to reference an object to determine 
 type while attempting to generate tags.  If this class is in the module where 
 the tags are being generated, this can cause a ClassNotFoundException.
 This error is being generated multiple times while running a Trinidad Build:
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.Date 
 ListProvider 
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProv 
 ider 
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202) 
 at java.security.AccessController.doPrivileged(Native Method) 
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307) 
 at 
 org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL 
 oader.java:195) 
 at 
 org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
 m.java:255) 
 at 
 org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
 m.java:274) 
 at 
 org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. 
 java:214) 
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248) 
 at java.lang.Class.forName0(Native Method) 
 at java.lang.Class.forName(Class.java:169) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 
 ctTagGenerator.resolveType(AbstractTagGenerator.java:247) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid 
 adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96
  
 ) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 
 We need to handle this accordingly



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

[jira] [Resolved] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code

2013-11-06 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2425.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

r1539418 | sobryan | 2013-11-06 18:20:22 + | 6 lines
Changed paths:
   M /myfaces/trinidad/trunk/pom.xml
   M /myfaces/trinidad/trunk/trinidad-impl/pom.xml

TRINIDAD-2425 - New plugins issue a warning on unavailability of uncompiled code

* Added a dependency section to the plugin definition imll
* Changed plugin dependency to be 2.0.8 instead of 2.0.8-SNAPSHOT

Until 2.0.8 is officially released, you'll need to build the plugins from the 
tag @ 
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8


 New plugins issue a warning on unavailability of uncompiled code
 

 Key: TRINIDAD-2425
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Affects Versions: 2.1.0-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
Priority: Blocker
 Fix For: 2.1.0-core

   Original Estimate: 24h
  Remaining Estimate: 24h

 The current 2.0.8 tag candidate tries to reference an object to determine 
 type while attempting to generate tags.  If this class is in the module where 
 the tags are being generated, this can cause a ClassNotFoundException.
 This error is being generated multiple times while running a Trinidad Build:
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.Date 
 ListProvider 
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProv 
 ider 
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202) 
 at java.security.AccessController.doPrivileged(Native Method) 
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190) 
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307) 
 at 
 org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL 
 oader.java:195) 
 at 
 org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
 m.java:255) 
 at 
 org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal 
 m.java:274) 
 at 
 org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. 
 java:214) 
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248) 
 at java.lang.Class.forName0(Native Method) 
 at java.lang.Class.forName(Class.java:169) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 
 ctTagGenerator.resolveType(AbstractTagGenerator.java:247) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid 
 adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96
  
 ) 
 at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra 
 We need to handle this accordingly



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

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Scott O'Bryan

Thanks for the input guys.  Any other votes?  I'll likely try to close this 
later this evening.

-- 
Scott O'Bryan

On November 6, 2013 at 2:43:33 PM, Blake Sullivan (blake.sulli...@oracle.com) 
wrote:

+1 for me as well.  Presumably we won't run into this problem later since the 
tags are generated in impl and Enums showing up in their api should be in the 
api package.  We could have this problem if we added enum support to 
components, but the component generation has access to the component metadata, 
which knows that this is an enum case.

-- Blake Sullivan

On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:

Hey Scott -

Great, thanks for tracking this down.  +1 for me then.

Andy



On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1.  I was able to fix this issue in the trinidad poms 
by adding:

        dependencies
          dependency
            groupIdorg.apache.myfaces.trinidad/groupId
            artifactIdtrinidad-api/artifactId
            version${project.version}/version
           /dependency
         /dependencies

To the maven-faces plugin definition in trinidad-impl.  So  I'll handle the 
ticket under trinidad and make sure its part of the next release.  The key was 
found in the maven class loading guide:

http://maven.apache.org/guides/mini/guide-maven-classloading.html

I noticed that the error was being issued in the impl package which should have 
had access to the api.  But the dependencies are only explicitly available to 
the javacc plugin or can be referenced manually by the mojo.  Our mojo doesn't 
handle dependencies, so the configuration is necessary.  Might be nice to add 
it at some point though.

Andy, does this work for you?

-- 
Scott O'Bryan

On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:

Andy, 

Yeah, I was seeing this too.  I was trying to track this as part of my work for 
the next Trinidad release, but I think your right.  This may be handled better 
in the plugin.  At the very least we should evaluate it.  What's happening here 
is a new check was added to test if a class for an attribute happens to be an 
enumeration.  In the case where we get the error, DateListProvider hasn't been 
built yet since the plugins generate the source BEFORE the plugins are built.

I'm going to generate a JIRA ticket and I for one think we need to fix this 
issue before releasing the plugins.  As such. my vote is a -1 pending this 
issue.
-- 
Scott O'Bryan

On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) 
wrote:

Hey Scott -

I attempted to do a clean Trinidad build against the new plugins.  I happened 
to notice this exception during the build:

 [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ 
 trinidad-impl ---
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.DateListProvider
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProvider
     at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:169)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
     at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
     at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84

[RESULT] [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Scott O'Bryan

This vote is now closed and has passed.  We have 4 binding +1 votes:

Blake Sullivan
Andy Schwartz
Max Starets
Scott O'Bryan

Thanks to everyone who voted, I'll prepare the artifacts and the announcement.

-- 
Scott O'Bryan

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Scott O'Bryan

Thanks everyone.  The vote is now closed.
-- 
Scott O'Bryan

On November 6, 2013 at 3:46:39 PM, Max Starets (max.star...@oracle.com) wrote:

+1

Max
On 11/6/2013 5:42 PM, Scott O'Bryan wrote:
Thanks for the input guys.  Any other votes?  I'll likely try to close this 
later this evening.

-- 
Scott O'Bryan

On November 6, 2013 at 2:43:33 PM, Blake Sullivan (blake.sulli...@oracle.com) 
wrote:

+1 for me as well.  Presumably we won't run into this problem later since the 
tags are generated in impl and Enums showing up in their api should be in the 
api package.  We could have this problem if we added enum support to 
components, but the component generation has access to the component metadata, 
which knows that this is an enum case.

-- Blake Sullivan

On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:

Hey Scott -

Great, thanks for tracking this down.  +1 for me then.

Andy



On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1.  I was able to fix this issue in the trinidad poms 
by adding:

        dependencies
          dependency
            groupIdorg.apache.myfaces.trinidad/groupId
            artifactIdtrinidad-api/artifactId
            version${project.version}/version
           /dependency
         /dependencies

To the maven-faces plugin definition in trinidad-impl.  So  I'll handle the 
ticket under trinidad and make sure its part of the next release.  The key was 
found in the maven class loading guide:

http://maven.apache.org/guides/mini/guide-maven-classloading.html

I noticed that the error was being issued in the impl package which should have 
had access to the api.  But the dependencies are only explicitly available to 
the javacc plugin or can be referenced manually by the mojo.  Our mojo doesn't 
handle dependencies, so the configuration is necessary.  Might be nice to add 
it at some point though.

Andy, does this work for you?

-- 
Scott O'Bryan

On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:

Andy, 

Yeah, I was seeing this too.  I was trying to track this as part of my work for 
the next Trinidad release, but I think your right.  This may be handled better 
in the plugin.  At the very least we should evaluate it.  What's happening here 
is a new check was added to test if a class for an attribute happens to be an 
enumeration.  In the case where we get the error, DateListProvider hasn't been 
built yet since the plugins generate the source BEFORE the plugins are built.

I'm going to generate a JIRA ticket and I for one think we need to fix this 
issue before releasing the plugins.  As such. my vote is a -1 pending this 
issue.
-- 
Scott O'Bryan

On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) 
wrote:

Hey Scott -

I attempted to do a clean Trinidad build against the new plugins.  I happened 
to notice this exception during the build:

 [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ 
 trinidad-impl ---
 [INFO] ClassNotFound error resolving type 
 org.apache.myfaces.trinidad.model.DateListProvider
 java.lang.ClassNotFoundException: 
 org.apache.myfaces.trinidad.model.DateListProvider
     at 
 org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
     at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:169)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
     at 
 org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
     at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
     at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153

[TRINIDAD] JIRA tickets for next Trinidad release

2013-11-05 Thread Scott O'Bryan

Okay everyone, while the vote for Trinidad Maven Plugins is underway, I would 
like to know which uncommitted JIRA tickets need to be in this release.  My 
goal is to begin the Trinidad release just after the plugins are released, so 
please reply promptly if you need a patch committed for the next release.

Thanks,
Scott O'Bryan

Re: [TRINIDAD] JIRA tickets for next Trinidad release

2013-11-05 Thread Scott O'Bryan

Thanks Cédric, I'll add it to the list and try to get to it soon.  Just to 
confirm, these all are going to go into Trinidad 2.1, not 2.0.

-- 
Scott O'Bryan

On November 5, 2013 at 7:40:20 AM, Cédric Durmont (cdurm...@gmail.com) wrote:

Hi Scott,

As a Trinidad user, I apply the patches for these issues and compile my own 
version of Trinidad, so, it would be nice if you could commit those :
TRINIDAD-2211 StateUtils$Saver illegally accessing private 
UIXComponentBase$ComponentSystemEventListenerWrapper
TRINIDAD-2216 The partialSubmit does not work with JSF 2 RI (okay this one 
seems to be in 2.1.x, but not in the stable 2.0.x branch)
TRINIDAD-1107 scrolling of content

Thanks
Cedric Durmont


2013/11/5 Scott O'Bryan darkar...@gmail.com
Okay everyone, while the vote for Trinidad Maven Plugins is underway, I would 
like to know which uncommitted JIRA tickets need to be in this release.  My 
goal is to begin the Trinidad release just after the plugins are released, so 
please reply promptly if you need a patch committed for the next release.

Thanks,
Scott O'Bryan

[jira] [Resolved] (TRINIDAD-2405) Allow numberConverter to specify roundingmode

2013-11-04 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2405.
-

   Resolution: Fixed
Fix Version/s: 2.0.8-plugins
 Assignee: Jeanne Waldman

This was never closed even though it was committed

 Allow numberConverter to specify roundingmode
 -

 Key: TRINIDAD-2405
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2405
 Project: MyFaces Trinidad
  Issue Type: Improvement
Reporter: Yee-Wah Lee
Assignee: Jeanne Waldman
Priority: Minor
 Fix For: 2.0.8-plugins

 Attachments: TrinPlugin_2405_numberConverterRoundingCode.diff, 
 TrinTrunk_2405_numberConverterRounding.diff, 
 TrinTrunk_2405_numberConverterRounding_xsdfix.diff


 NumberFormat has a method setRoundingMode() which controls how numbers are 
 rounded. The JDK default is RoundingMode.HALF_EVEN. 
 This tracks adding an attribute to the numberConverter so that the rounding 
 mode can be set, instead of always using JDK defaults. 



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

[jira] [Resolved] (TRINIDAD-2200) Allow non-http://java.sun.com/xml/ns/javaee/faces/design-time-metadata namespaced elements in the global-metadata

2013-11-04 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2200.
-

   Resolution: Fixed
Fix Version/s: 2.0.8-plugins

Issue merged in by Andrew Robinson

r1231359 | arobinson74 | 2012-01-13 22:30:41 + | 1 line
Changed paths:
   M 
/myfaces/trinidad-maven/trunk/maven-faces-plugin/src/main/resources/org/apache/myfaces/trinidadbuild/plugin/faces/resources/transform20.xsl

TRINIDAD-2200 - Allow non-fmd data in the global-metadata block. Also fixed the 
component metadata and property-metadata to recursively copy their nodes since 
there is no generic node matching


 Allow non-http://java.sun.com/xml/ns/javaee/faces/design-time-metadata; 
 namespaced elements in the global-metadata
 ---

 Key: TRINIDAD-2200
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2200
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions: 2.0.8-plugins
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Fix For: 2.0.8-plugins


 Our transform20.xsl permits unknown namespaced elements under 
 property-extension and facet-extension, but not 
 faces-config-extension/fmd:global-metadata. It would be helpful to certain 
 IDEs and frameworks built on Trinidad to allow for additional elements to be 
 supported in the same way that they are supported by property-extension and 
 facet-extension.



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

[VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-04 Thread Scott O'Bryan

I was running the tasks needed to release the Trinidad Maven Plugins version 
2.0.8 which is needed as a prerequisite to a Trinidad release.  I have compiled 
the Release Notes[1] for the 2.0.8 release.  

I have generated the tag [2] and have deployed the built artifacts to nexus 
[3].  Lastly I have included a source archive [4].  I've done preliminary 
testing and building, updated the plugins to comply with checkstyle, and made 
sure the build passed rat:check.

Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now 
and vote.

Please note: 

This vote is majority approval with a minimum of three +1 votes (see [5]). 

 
[ ] +1 for community members who have reviewed the bits  
[ ] +0 
[ ] -1 for fatal flaws that should cause these bits not to be released, and 
why.. 
 

Thanks, 
  Scott O'Bryan

[1] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290
[2] 
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8
[3] https://repository.apache.org/content/repositories/orgapachemyfaces-069
[4] 
https://repository.apache.org/content/repositories/orgapachemyfaces-069/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.8/maven-plugin-parent-2.0.8-source-release.zip
[5] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [DISCUSS] trinidad.next

2013-10-30 Thread Scott O'Bryan

Hey guys, I understand some of the frustration, but MyFaces 2.1 and Trinidad
2.0 is an invalid configuration. Why would a release of Trinidad 2.1 (which is
designed for JSF 2.1) not solve this issue.
--
Scott O'Bryan
Sent with Airmail

On October 30, 2013 at 1:28:20 AM, Gerhard Petracek
(gerhard.petra...@gmail.com) wrote:

hi eduardo,

if so: please file the corresponding jira-ticket/s.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2013/10/30 Contrib gcont...@cibinetonline.com
There are some bugfixes on MyFaces 2.1, and projects having Trinidad 2.0 as
part of the stack, cannot update it due this.

Regards,

Eduardo

El 28/10/13 10:09, Gerhard Petracek escribió:
it isn't only about one release.
e.g. 2.1.0 was just skipped and at least a part is broken since months (see [1]
and [2]).
therefore i called this thread trinidad.next instead of trinidad 2.1.1.

imo:
the current situation isn't acceptable for users.
committers who work on trinidad on a regular basis should also do releases on a
regular basis.

regards,
gerhard

[1] https://issues.apache.org/jira/browse/TRINIDAD-2422
[2] https://builds.apache.org/job/Trinidad%20Core%20Trunk%20(snapshot)/

2013/10/18 Hazem Saleh haz...@apache.org
+1 for a release too.

On Fri, Oct 18, 2013 at 2:12 PM, Werner Punz werner.p...@gmail.com wrote:
Am 17.10.13 22:47, schrieb Gerhard Petracek:

hi @ all,

we haven't seen a trinidad release for almost 20 months.
it's known that other projects are based on trinidad and therefore it's
obvious that they have to use snapshot versions.

imo:
since there are commits on a regular basis, there should be also
releases on a regular basis.

regards,
gerhard
+1 for a release

Werner

--
Hazem Saleh

Author of JavaScript Unit Testing book:
http://www.amazon.com/dp/1782160620/

Co-author of (The Definitive Guide to Apache MyFaces and Facelets) book:
http://www.amazon.com/-/e/B002M052KY

DeveloperWorks Contributing Author
https://www.ibm.com/developerworks/mydeveloperworks/blogs/hazem/entry/ibm_developerworks_contributing_author?lang=en_us

An Apache committer, IBMer, and a technical speaker

Twitter: http://www.twitter.com/hazems

[jira] [Commented] (TRINIDAD-2422) repo out of sync

2013-10-30 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2422:
-

Actually, this was fixed originally by reverting the version of the plugins 
back to 2.0.8-SNAPSHOT.  We never released them so the version number should 
not have been increased.  Looks like the check for TRINIDAD-2405 incremented 
these version numbers in Trinidad.

 repo out of sync
 

 Key: TRINIDAD-2422
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2422
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Reporter: Gerhard Petracek
Assignee: Jeanne Waldman
Priority: Critical
 Attachments: TRINIDAD-2422.patch


 http://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/ is out of sync 
 and therefore http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ fails 
 to build



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

Re: [DISCUSS] trinidad.next

2013-10-30 Thread Scott O'Bryan

Gerhard and Devs,

The problem is there was some 2.1 stuff added to the ExternalContext I believe. 
 At any rate, I agree with you and I've managed to free up some free time to 
get a release.  So here is what I suggest:

1) I'm going to begin the release of the Trinidad plugins.  With voting this 
should give us a couple of days to get the main trinidad 2.1 release where we 
want it.

2) I'm hearing concerns about some of the functionality, so while the Trinidad 
Plugin release is underway, let's try and figure out which uncomiited community 
patches are out there and should make this release.  Getting help from you guys 
on which bugs are important would be a huge help because there is a lot in our 
bug queue and it would take me a long time to sort everything out.

3) I've already fixed Gerhard's issue he raised below.  You're 100% right, this 
shouldn't have happened.  There is a slight build with the Jenkins sanity and 
I'm taking a look at that now, but the snapshots are building fine.

4) Let's get through this release and then we'll talk about future steps once 
the release is complete.

Sounds like a plan?
-- 
Scott O'Bryan

On October 30, 2013 at 7:59:38 AM, Gerhard Petracek 
(gerhard.petra...@gmail.com) wrote:

you

Re: [DISCUSS] trinidad.next

2013-10-30 Thread Scott O'Bryan

Gerhard, what he's saying is that we have several cases that require a base 
implementation.  Mostly they are for cases that are outside of the JSF 
lifecycle.  It MAY be possible to retrofit these cases with the 
ExternalContextFactory and the wrapper, but this work hasn't been done yet.

-- 
Scott O'Bryan

On October 30, 2013 at 5:13:41 PM, Gerhard Petracek 
(gerhard.petra...@gmail.com) wrote:

hi blake,

many other libs don't have an issue with using the std. wrapper approach (+ 
ExternalContextWrapper).
- without concrete details we can't follow, since ExternalContextWrapper was 
introduced for keeping libs as stable/compatible as possible (across spec. 
revisions).

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/30 Blake Sullivan blake.sulli...@oracle.com
That's only if you are wrapping another ExternalContext.  If you need to create 
an ExternalContext out of thin air, then any new abstract methods are a 
problem.  Essentially, the JSF specification made an incompatible api change 
between JSF 2.0 and 2.1.

-- Blake Sullivan

On Oct 30, 2013, at 3:49 PM, Gerhard Petracek wrote:

@ExternalContext:
there shouldn't be an issue due to ExternalContextWrapper.

in any case +1 for the rest.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2013/10/30 Scott O'Bryan darkar...@gmail.com
Gerhard and Devs,

The problem is there was some 2.1 stuff added to the ExternalContext I believe. 
 At any rate, I agree with you and I've managed to free up some free time to 
get a release.  So here is what I suggest:

1) I'm going to begin the release of the Trinidad plugins.  With voting this 
should give us a couple of days to get the main trinidad 2.1 release where we 
want it.

2) I'm hearing concerns about some of the functionality, so while the Trinidad 
Plugin release is underway, let's try and figure out which uncomiited community 
patches are out there and should make this release.  Getting help from you guys 
on which bugs are important would be a huge help because there is a lot in our 
bug queue and it would take me a long time to sort everything out.

3) I've already fixed Gerhard's issue he raised below.  You're 100% right, this 
shouldn't have happened.  There is a slight build with the Jenkins sanity and 
I'm taking a look at that now, but the snapshots are building fine.

4) Let's get through this release and then we'll talk about future steps once 
the release is complete.

Sounds like a plan?
-- 
Scott O'Bryan

On October 30, 2013 at 7:59:38 AM, Gerhard Petracek 
(gerhard.petra...@gmail.com) wrote:

you

[jira] [Comment Edited] (TRINIDAD-2408) TrPage._getTextContent is not working in IE10

2013-09-27 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan edited comment on TRINIDAD-2408 at 9/27/13 12:41 PM:
---

Committed to trunk.  Please answer Robert about whether this can be applied to 
1.2.x or not before closing this issue.

  was (Author: darkarena):
Committed to trunk.  Please answer Robert about whether this can be applied 
to 1.2.x or not.
  
 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core, 2.1.0-core

 Attachments: 17285610.patch, 17285610_updated.patch, IE10-Test3.zip


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.

--
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-2408) TrPage._getTextContent is not working in IE10

2013-09-27 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2408:
-

Committed to trunk.  Please answer Robert about whether this can be applied to 
1.2.x or not.

 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core, 2.1.0-core

 Attachments: 17285610.patch, 17285610_updated.patch, IE10-Test3.zip


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.

--
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] [Resolved] (TRINIDAD-2399) support css client side rules in skinning framework

2013-09-16 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan resolved TRINIDAD-2399.
-

   Resolution: Fixed
Fix Version/s: 2.1.0-core

 support css client side rules in skinning framework
 ---

 Key: TRINIDAD-2399
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2399
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Scott O'Bryan
 Fix For: 2.1.0-core

 Attachments: jira-2399.patch


 This ER is for introducing client side css rule support in skinning framework.
 Here's a list of known CSS at-rules:
 @document - uses nested selectors that need to be resolved
 @font-face - probably safe to blindly pass through
 @keyframes - probably safe to blindly pass through
 @media - uses nested selectors that need to be resolved
 @page - probably safe to blindly pass through
 @supports - uses nested selectors that need to be resolved
 These rules can be split into two based on its usage:
 @document, @keyframes, @media, @support uses following syntax:
 @rule {
   selector 
   { 
 property : value; 
 property : value; 
 property : value; 
   }
 }
 @font-face and @page uses following syntax:
 @rule {
   property : value; 
   property : value; 
   property : value; 
 }

--
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] [Reopened] (TRINIDAD-2414) non namespaced selectors are getting compressed with skin compression turned on

2013-09-16 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan reopened TRINIDAD-2414:
-

  Assignee: Scott O'Bryan

This issue was apparently not supposed to be closed yet

 non namespaced selectors are getting compressed with skin compression turned 
 on
 ---

 Key: TRINIDAD-2414
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2414
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Assignee: Scott O'Bryan
 Attachments: jira-2414.patch


 Selectors such as:
 .AFSelector { ... }
 was getting rendered in both compressed and uncompressed way with compression 
 turned on.
 But this was not happening for
 .AFSelector af|foo { ... }
 af|foo.AFSelector { ... }
 This was rendered as compressed with compression turned on. 
 The solution is to render the non namespaced selectors only in un compressed 
 format.

--
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-2408) TrPage._getTextContent is not working in IE10

2013-08-20 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan updated TRINIDAD-2408:


   Resolution: Fixed
Fix Version/s: 2.1.0-core
   2.0.2-core
 Assignee: Scott O'Bryan
   Status: Resolved  (was: Patch Available)

 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core, 2.1.0-core

 Attachments: 17285610.patch, IE10-Test3.zip


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.

--
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-2408) TrPage._getTextContent is not working in IE10

2013-08-15 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2408:
-

The TrPage._getTextContent is an internal API.  I noticed you seem to have a 
bug in ADFFaces, but is something broken in Trinidad?

Scott

 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
 Attachments: 17285610.patch


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.

--
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-2408) TrPage._getTextContent is not working in IE10

2013-08-15 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2408:
-

Cool, then for posterity, can you please post the test case your trying to fix 
here?  I understand Oracle does it's own tracking to scope out work for Apache 
donations, but Trinidad tickets should be self contained since it's an Apache 
project.

Now for a question regarding your implementation.  The fix looks pretty simple, 
but if this is for IE10 only, I'm wondering if this code shouldn't be in the 
agent?

 TrPage._getTextContent is not working in IE10
 -

 Key: TRINIDAD-2408
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
 Environment: IE-10
Reporter: Paresh Kumar Acharya
 Attachments: 17285610.patch


 The TrPage._getTextContent() API is not working on ie 10. On ie10 the 
 innerText attribute and the text attribute doesn't work on IE10. In IE 10 
 textContent attribute shoule be used.

--
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-2408) TrPage._getTextContent is not working in IE10

2013-08-15 Thread Scott O'Bryan (JIRA)

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

Scott O'Bryan edited comment on TRINIDAD-2408 at 8/15/13 5:13 PM:
--

Cool, then for posterity, can you please post the test case your trying to fix
here? I understand Oracle does it's own tracking to scope out work for Apache
donations, but Trinidad tickets should be self contained since it's an Apache
project.

was (Author: darkarena):
Cool, then for posterity, can you please post the test case your trying to
fix here? I understand Oracle does it's own tracking to scope out work for
Apache donations, but Trinidad tickets should be self contained since it's an
Apache project.

Now for a question regarding your implementation. The fix looks pretty simple,
but if this is for IE10 only, I'm wondering if this code shouldn't be in the
agent?

TrPage._getTextContent is not working in IE10
-

Key: TRINIDAD-2408
URL: https://issues.apache.org/jira/browse/TRINIDAD-2408
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-core, 2.1.0-core
Environment: IE-10
Reporter: Paresh Kumar Acharya
Attachments: 17285610.patch

The TrPage._getTextContent() API is not working on ie 10. On ie10 the
innerText attribute and the text attribute doesn't work on IE10. In IE 10
textContent attribute shoule be used.

--
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-2394) LabeledFacesMessage is not appropriately serializable

2013-05-22 Thread Scott O'Bryan (JIRA)


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

Scott O'Bryan commented on TRINIDAD-2394:
-

To clarify this issue, this API will allow us to evaluate any EL contained in 
the LabeledFacesMessage.  This is important if the LabeledFacesMessage was 
being sent to another server, like a portlet or other type of consumer, where 
the EL engine may not be able to evaluate the EL.  By executing this method, we 
could evaluate the EL before hand and send its value (not the expression) over 
the wire.

 LabeledFacesMessage is not appropriately serializable
 -

 Key: TRINIDAD-2394
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2394
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
 Fix For: 2.0.2-core


 LabeledFacesMessage is derived from FacesMessage which is serializable.  The 
 issue is that the label in LabeledFacesMessage is an object and is expected 
 to sometimes contain a ValueExpression.  When trying to serialize this class 
 over the wire, the Label needs to be converted into a string before it is 
 sent over the wire.  As such, we need a public API to convert the value into 
 a string so that, if an implementation needs to serialize the faces message, 
 it can do so.

--
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-2390) More specific URL encoding

Scott O'Bryan created TRINIDAD-2390:
---

 Summary: More specific URL encoding
 Key: TRINIDAD-2390
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2390
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Portlet
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan


The ExternalContext does URL encoding for JSF.  Although JSF 2.0 introduced 
some more specific encoding types, there are still other encoding types which 
are not covered.  In an effort to help remove some ambiguity and open the door 
for other types of remote solutions, we need a URL Encoder mechanism which is 
separate from JSF but it also integrated with it in order to ease URL encoding 
for our components.

--
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-2390) More specific URL encoding


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

Scott O'Bryan updated TRINIDAD-2390:


Status: Patch Available  (was: Open)

 More specific URL encoding
 --

 Key: TRINIDAD-2390
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2390
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Portlet
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan

 The ExternalContext does URL encoding for JSF.  Although JSF 2.0 introduced 
 some more specific encoding types, there are still other encoding types which 
 are not covered.  In an effort to help remove some ambiguity and open the 
 door for other types of remote solutions, we need a URL Encoder mechanism 
 which is separate from JSF but it also integrated with it in order to ease 
 URL encoding for our components.

--
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-2390) More specific URL encoding


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

Scott O'Bryan updated TRINIDAD-2390:


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

txn 1485037

 More specific URL encoding
 --

 Key: TRINIDAD-2390
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2390
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Portlet
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan
 Fix For: 2.1.0-core


 The ExternalContext does URL encoding for JSF.  Although JSF 2.0 introduced 
 some more specific encoding types, there are still other encoding types which 
 are not covered.  In an effort to help remove some ambiguity and open the 
 door for other types of remote solutions, we need a URL Encoder mechanism 
 which is separate from JSF but it also integrated with it in order to ease 
 URL encoding for our components.

--
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-2391) Enhancements to allow for custom FileUpload code

Scott O'Bryan created TRINIDAD-2391:
---

 Summary: Enhancements to allow for custom FileUpload code
 Key: TRINIDAD-2391
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2391
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.1-core
Reporter: Scott O'Bryan
Assignee: Scott O'Bryan


The FileUpload code in Trinidad is handled through a configurator. This system 
expects to be the only system to process file uploads and is a relatively 
closed system.  Some enhancements should be made to the internal implementation 
of the file upload code that could allow extensions to implement some custom 
logic for handling uploaded files and allow them to be plugged into the 
FileUpload framework. 

--
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-2391) Enhancements to allow for custom FileUpload code