from:"Andy Schwartz"

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

Andy Schwartz commented on TRINIDAD-2468:
-

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

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

This patch does the following:

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

We can now simulate the problem by:

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

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

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

Without the fix, we see the following sequence:

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

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

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

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

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

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

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

FileSystemStyleCache: split style sheet concurrency issue
-

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

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


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

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

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

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

This patch does the following:

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

We can now simulate the problem by:

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

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

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

Without the fix, we see the following sequence:

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

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

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

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

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

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

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


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

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

This patch does the following:

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

We can now simulate the problem by:

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

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

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

Without the fix, we see the following sequence:

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

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

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

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

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

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

This patch does the following:

We can now simulate the problem by:

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

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

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

Without the fix, we see the following sequence:

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

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

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

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

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

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

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

This patch does the following:

We can now simulate the problem by:

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

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

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

Without the fix, we see the following sequence:

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

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

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

Andy Schwartz commented on TRINIDAD-2468:
-

Uploaded a new version of the fix:

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

That includes some minor InterruptedException handling tweaks.

FileSystemStyleCache: split style sheet concurrency issue
-

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

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

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

2014-04-15 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2468:
---

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


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

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

In particular:

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

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

-  foo-desktop-gecko.css

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

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

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

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

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

This triggers the following sequence:

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

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

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



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

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

2014-04-15 Thread Andy Schwartz (JIRA)

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

Andy Schwartz updated TRINIDAD-2468:

Status: Patch Available (was: Open)

FileSystemStyleCache: split style sheet concurrency issue
-

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

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

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

2014-04-15 Thread Andy Schwartz (JIRA)

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

Andy Schwartz commented on TRINIDAD-2468:
-

The provided patch:

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

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

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

FileSystemStyleCache: split style sheet concurrency issue
-

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

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

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

2014-03-25 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2463:
---

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


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

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

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

This is bad.

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

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

We need to do two things:

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



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

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

2014-03-25 Thread Andy Schwartz (JIRA)

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

Andy Schwartz updated TRINIDAD-2463:

Status: Patch Available (was: Open)

Concurrency issues in CachingResourceLoader
---

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

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

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

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

2014-03-25 Thread Andy Schwartz (JIRA)

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

Andy Schwartz commented on TRINIDAD-2463:
-

The attached patch addresses this:

1. Make CachingResourceLoader.URLStreamHandlerImpl thread safe.

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

And this:

2. Make CachingResourceLoader more tolerant of content length changes.

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

Concurrency issues in CachingResourceLoader
---

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

Re: [Trinidad] New API addition for Trinidad's UIXEditableValueTemplate

2014-03-24 Thread Andy Schwartz

+1

Andy


 On Mar 21, 2014, at 5:07 PM, Gabrielle Crawford 
 gabrielle.crawf...@oracle.com wrote:
 
 +1
 
 On Mar 19, 2014, at 1:25 PM, Ji Kim wrote:
 
 For note =
 
 This is to allow components and etcetera to listen to this event by adding a 
 listener in the new UIXEditableValueTemplate.addValueUpdatedListener API. 
 
 The pro of adding this event + listener is that various components can then 
 listen when the value has been updated in the model. 
 
 This is beneficial in 
 1) Clearing up any data that would have been persisted for some reason [i.e. 
 if the app wished to keep a temporary value of a component using some kind 
 of polling from client to server to not lose any dirty data {i.e. how 
 confluence wiki allows users to preserves the old states}]. 
 2) To avoid sending a certain asynchronous dirty data from the client to the 
 server 
 
 Thanks!
 
 On 3/19/2014 12:44 PM, Ji Kim wrote:
 So as requested I am sending out a separate email to get responses from the 
 crowd regarding this JIRA 
 [https://issues.apache.org/jira/browse/TRINIDAD-2459].
 
 The change is to add 2 new APIs to Trinidad's UIXEditableValueTemplate =
 
 public void addValueUpdatedListener(ValueUpdatedListener listener) 
 { 
   super.addFacesListener (listener); 
 } 
 
 public void removeValueUpdatedListener (ValueUpdatedListener listener) 
 { 
   super.removeFacesListener (listener); 
 } 
 
 where ValueUpdatedEvent is queued within the updateModel method/phase.
 
 public void updateModel(FacesContext context)
 {
 ...
 try
 {
   Object localValue = getLocalValue();
   expression.setValue(context.getELContext(), localValue);
   setValue(null);
   setLocalValueSet(false);
   (new ValueUpdatedEvent(this)).queue();
 ...
 }
 
 Thanks!

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

2014-01-23 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2447:


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

Implemented fix as described above.

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

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

 Attachments: trinidad-2447.patch


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



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

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

2014-01-22 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2447:
---

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


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

isCompositeComponent() performs the following check:

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

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

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

PropertyKey propertyKey = _getPropertyKey(key);

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

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

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






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

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

2014-01-22 Thread Andy Schwartz (JIRA)


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

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

The proposed fix does two things:

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

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


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

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

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


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



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

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

2014-01-22 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2447:


Status: Patch Available  (was: Open)

 UIComponent.isCompositeComponent() is slow for UIXComponents
 

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


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



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

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

2014-01-10 Thread Andy Schwartz (JIRA)

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

Andy Schwartz updated TRINIDAD-2443:

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

Reduced the logger level to INFO.

Reduce severity of component binding reuse message
--

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

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

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

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

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

2014-01-09 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2443:
---

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


As part of our changes for:

TRINIDAD-2409 improve diagnostics during tag execution component binding 
failures

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

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

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

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

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

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

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



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

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

2014-01-09 Thread Andy Schwartz (JIRA)

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

Andy Schwartz updated TRINIDAD-2443:

Status: Patch Available (was: Open)

Reduce severity of component binding reuse message
--

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

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Andy Schwartz

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

Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8

2013-11-06 Thread Andy Schwartz

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

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

2013-11-05 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2410:


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

 LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND
 

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

 Attachments: trinidad-2410.patch


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



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

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

2013-08-26 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2410:
---

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


UIXEditableValue includes the following two property key definitions:

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

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-08-26 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2410:


Status: Patch Available  (was: Open)

 LOCAL_VALUE_SET_KEY and SUBMITTED_VALUE_KEY should specify CAP_NOT_BOUND
 

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Trinidad] Anyone care to review fix for TRINIDAD-2410?

2013-08-26 Thread Andy Schwartz

Gang -

I encountered this issue with UIXEditableValue recently:

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

 UIXEditableValue includes the following two property key definitions:

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

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

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

Anyone want to review the patch here:

https://issues.apache.org/jira/secure/attachment/12599951/trinidad-2410.patch

Before I commit?

Seems like a trivial issue and fix, but wouldn't mind a second pair of eyes
on it.

Andy

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

2013-07-27 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2404:
---

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


The following property keys in UIXEditableValue:

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

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-07-27 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2404:


Status: Patch Available  (was: Open)

 UIXEditableValue property keys missing CAP_NOT_BOUND
 

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-03-08 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2355:


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

Commit Anshu's patch in r1454406.

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

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

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-02-28 Thread Andy Schwartz (JIRA)


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

Andy Schwartz updated TRINIDAD-2360:


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

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

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

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-02-28 Thread Andy Schwartz (JIRA)


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

Andy Schwartz commented on TRINIDAD-2360:
-

I committed this version of the fix to trunk:

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

Thanks for working on this issue Anshu!

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

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-02-04 Thread Andy Schwartz (JIRA)

Andy Schwartz created TRINIDAD-2359:
---

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


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

The Mojarra issue is described here:

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

Two problems with this:

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-02-04 Thread Andy Schwartz (JIRA)


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

Andy Schwartz commented on TRINIDAD-2359:
-

More details on #2 above...

GlobalConfiguratorImpl._isSetRequestBugPresent() performs the following test:


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

  ec.setRequest(new TestRequest(orig));

  _sHasSetRequestBug = !TestRequest.isTestParamPresent(ec);

Where TestRequest looks like this:

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

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

  return super.getParameter(string);
}

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

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

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



 ClearRequestExternalContext wrapper applied unnecessarily
 -

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

2013-02-04 Thread Andy Schwartz (JIRA)

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

Andy Schwartz commented on TRINIDAD-2359:
-

This patch:

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

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

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

ClearRequestExternalContext wrapper applied unnecessarily
-

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Trinidad] Query regarding the popup window size in IE

2013-01-16 Thread Andy Schwartz

Hi Anshu -

(Adding [Trinidad] to the subject to clarify that this issue is
Trinidad-specific.)


On Fri, Dec 14, 2012 at 5:19 AM, Anshu Jain anshu.x.j...@oracle.com wrote:

  Hi,

 I noticed a strange behavior in when a dialog box is opened having a fixed
 size. In this example, the width of the popup window is set to 600 px and
 height 600 px.
 When the popup is opened using a button, the size of the popup window in
 IE (7, 8 and 9) is 640x684. Also, the frame size inside the popup is
 626x594.

 For the same case, in Mozilla Firefox and Chrome, the frame size opens to
 be 600x600.

 On analysis, I found that in the _sizeWin() method in Window.js, no
 execution is done for Chrome and Firefox, since the body object is null.



I am confused why this would be the case.  window.document.body should be
non-null by the time _sizeWin() is called in the onload handler.  Can you
double-check that window.document.body is definitely null and not that some
other logic in the method is diverging across browsers?




 ...
 var body =  theWindow.document.body;
 if (body)
 {
  ...
  ...
 }
 }

 But, in case of IE body object is not null, and newWidth and newHeight are
 calculated and the window is resized to an this new size which seems to be
 incorrect. Because of this part of the code, the popup window is never
 opened in the size defined and IE behaves in a different way than Friefox
 and Chrome.

 I tried bypassing this entire code and checked the popup window size, and
 found that without this code execution, the IE behaves in the same way as
 Firefox and Chrome and opens a popup with frame size as defined in the
 parameters.

 My query was that is there a special reason that this calculation is done
 for IE with Windows? Is the reason valid even in case of newer versions of
 IE like IE8 and IE9?



The intent of this (very old) sizing code is to attempt to ensure that
there is sufficient space to display the full contents of the window.  I
don't believe that there was ever an intention for this sizing logic to be
limited to IE.

Andy

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


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

Andy Schwartz updated TRINIDAD-2344:


Status: Patch Available  (was: Open)

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

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Andy Schwartz created TRINIDAD-2345:
---

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


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

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

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Andy Schwartz commented on TRINIDAD-2343:
-

Committed fix to trunk in r1415347.

 Hook for overriding UIXCollection temp var storage
 --

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

 Attachments: trinidad-2343.patch


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

Andy Schwartz updated TRINIDAD-2343:


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

 Hook for overriding UIXCollection temp var storage
 --

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

 Attachments: trinidad-2343.patch


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Andy Schwartz created TRINIDAD-2343:
---

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


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

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

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

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


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

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

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


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


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

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


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Trinidad] API: UIXCollection.setupELVariable()

2012-11-27 Thread Andy Schwartz

Gang -

As described in the following issue:

TRINIDAD-2343 Hook for overriding UIXCollection temp var storage
https://issues.apache.org/jira/browse/TRINIDAD-2343

I would like to expose a protected hook allow subclasses to provide
alternate storage for the temporary EL variables that are set up by
UIXCollection - ie. I want to provide a protected replacement for this
existing private method:

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

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

My proposal is to add the following new UIXCollection API:

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

(I picked the method name to match the related utility method on
TableUitls.)

If anyone has questions/comments on this new hook, please let me know.

Andy

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

Andy Schwartz created TRINIDAD-2344:
---

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


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

We addressed this in a one-off fashion here:

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

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

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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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