[jira] [Resolved] (TRINIDAD-2514) Make isEmailMode check more lenient
[ https://issues.apache.org/jira/browse/TRINIDAD-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2514. -- Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Blake Sullivan Fixed in revision 1631831 > Make isEmailMode check more lenient > --- > > Key: TRINIDAD-2514 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2514 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Components >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.1-core > > Attachments: trinTrunk2514.patch > > > Make the isEmailable check more lenient so that upper stack components can > add more options for how email generation should be handled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRINIDAD-2514) Make isEmailMode check more lenient
Blake Sullivan created TRINIDAD-2514: Summary: Make isEmailMode check more lenient Key: TRINIDAD-2514 URL: https://issues.apache.org/jira/browse/TRINIDAD-2514 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.0-core Reporter: Blake Sullivan Priority: Minor Make the isEmailable check more lenient so that upper stack components can add more options for how email generation should be handled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRINIDAD-2503) Extend testing improvements in 2501 and 2502 to RenderKit subclasses
[ https://issues.apache.org/jira/browse/TRINIDAD-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2503. -- Resolution: Fixed Resolved in 1,616,039 > Extend testing improvements in 2501 and 2502 to RenderKit subclasses > > > Key: TRINIDAD-2503 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2503 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Build >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Attachments: Trin-2503.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > Allow RenderKitTestCase subclasses to use the improvements in Trinidad-2501 > and Trindiad-2502 by moving the utility functions from CoreRenderKitTest to > RenderKitTestCase -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2503) Extend testing improvements in 2501 and 2502 to RenderKit subclasses
Blake Sullivan created TRINIDAD-2503: Summary: Extend testing improvements in 2501 and 2502 to RenderKit subclasses Key: TRINIDAD-2503 URL: https://issues.apache.org/jira/browse/TRINIDAD-2503 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 2.1.0-core Reporter: Blake Sullivan Assignee: Blake Sullivan Priority: Minor Allow RenderKitTestCase subclasses to use the improvements in Trinidad-2501 and Trindiad-2502 by moving the utility functions from CoreRenderKitTest to RenderKitTestCase -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2502) Finish RenderKit Test Improvements so we can always run all tests
[ https://issues.apache.org/jira/browse/TRINIDAD-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2502. -- Resolution: Fixed Fix Version/s: 2.1.1-core Fixed in revision 1,615,878 > Finish RenderKit Test Improvements so we can always run all tests > - > > Key: TRINIDAD-2502 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2502 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.1-core > > Attachments: trin-2502.patch > > Original Estimate: 4h > Remaining Estimate: 4h > > Finish adding per-test switches for right-to-left support and agent support > so that the tests pass when run in strict mode and then change the build > default to strict from lenient -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2502) Finish RenderKit Test Improvements so we can always run all tests
Blake Sullivan created TRINIDAD-2502: Summary: Finish RenderKit Test Improvements so we can always run all tests Key: TRINIDAD-2502 URL: https://issues.apache.org/jira/browse/TRINIDAD-2502 Project: MyFaces Trinidad Issue Type: Improvement Components: Build Affects Versions: 2.1.0-core Reporter: Blake Sullivan Priority: Minor Finish adding per-test switches for right-to-left support and agent support so that the tests pass when run in strict mode and then change the build default to strict from lenient -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2501) Renderkit Test Improvements
[ https://issues.apache.org/jira/browse/TRINIDAD-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2501: - Resolution: Fixed Fix Version/s: 2.1.1-core Status: Resolved (was: Patch Available) Resolved in 1,615,840 > Renderkit Test Improvements > --- > > Key: TRINIDAD-2501 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2501 > Project: MyFaces Trinidad > Issue Type: Improvement > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.1-core > > Attachments: trin-2501-2_1_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Improve RenderKit Tests by: > 1) Allowing the set of SuiteDefinition environment tests to be passed on the > command line > 2) Allowing the set of testScripts to be passed on the command line > 3) Allowing test scripts to specify the set of accessibility modes they don't > execute in > 4) Allowing test cases to specify the set of accessibility modes that they > don't execute in > 5) Cleaning up the code > 6) Fixing up the test scripts to set the unsupported accessibility modes so > only the tests are aren't supported on a particular accessibility mode are > skipped, rather than relying on the shotgun approach of running all of the > tests in lenient mode > 7) Fixing up the golden files to remove the test cases that shouldn't run -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2501) Renderkit Test Improvements
[ https://issues.apache.org/jira/browse/TRINIDAD-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085678#comment-14085678 ] Blake Sullivan commented on TRINIDAD-2501: -- Resolved in 1,615,840 > Renderkit Test Improvements > --- > > Key: TRINIDAD-2501 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2501 > Project: MyFaces Trinidad > Issue Type: Improvement >Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.1-core > > Attachments: trin-2501-2_1_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Improve RenderKit Tests by: > 1) Allowing the set of SuiteDefinition environment tests to be passed on the > command line > 2) Allowing the set of testScripts to be passed on the command line > 3) Allowing test scripts to specify the set of accessibility modes they don't > execute in > 4) Allowing test cases to specify the set of accessibility modes that they > don't execute in > 5) Cleaning up the code > 6) Fixing up the test scripts to set the unsupported accessibility modes so > only the tests are aren't supported on a particular accessibility mode are > skipped, rather than relying on the shotgun approach of running all of the > tests in lenient mode > 7) Fixing up the golden files to remove the test cases that shouldn't run -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2501) Renderkit Test Improvements
[ https://issues.apache.org/jira/browse/TRINIDAD-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2501: - Status: Patch Available (was: Open) > Renderkit Test Improvements > --- > > Key: TRINIDAD-2501 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2501 > Project: MyFaces Trinidad > Issue Type: Improvement > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > Improve RenderKit Tests by: > 1) Allowing the set of SuiteDefinition environment tests to be passed on the > command line > 2) Allowing the set of testScripts to be passed on the command line > 3) Allowing test scripts to specify the set of accessibility modes they don't > execute in > 4) Allowing test cases to specify the set of accessibility modes that they > don't execute in > 5) Cleaning up the code > 6) Fixing up the test scripts to set the unsupported accessibility modes so > only the tests are aren't supported on a particular accessibility mode are > skipped, rather than relying on the shotgun approach of running all of the > tests in lenient mode > 7) Fixing up the golden files to remove the test cases that shouldn't run -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2501) Renderkit Test Improvements
Blake Sullivan created TRINIDAD-2501: Summary: Renderkit Test Improvements Key: TRINIDAD-2501 URL: https://issues.apache.org/jira/browse/TRINIDAD-2501 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Blake Sullivan Assignee: Blake Sullivan Priority: Minor Improve RenderKit Tests by: 1) Allowing the set of SuiteDefinition environment tests to be passed on the command line 2) Allowing the set of testScripts to be passed on the command line 3) Allowing test scripts to specify the set of accessibility modes they don't execute in 4) Allowing test cases to specify the set of accessibility modes that they don't execute in 5) Cleaning up the code 6) Fixing up the test scripts to set the unsupported accessibility modes so only the tests are aren't supported on a particular accessibility mode are skipped, rather than relying on the shotgun approach of running all of the tests in lenient mode 7) Fixing up the golden files to remove the test cases that shouldn't run -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2494) Switch Trinidad Plugin Source Code to use Generics
[ https://issues.apache.org/jira/browse/TRINIDAD-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069792#comment-14069792 ] Blake Sullivan commented on TRINIDAD-2494: -- Resolved in reviison 1,612,454 > Switch Trinidad Plugin Source Code to use Generics > -- > > Key: TRINIDAD-2494 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2494 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Build >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan >Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.0-core > > Attachments: trinTrunkPlugins-2494_21.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > Switch Trinidad Plugins to use generics, cleaning up warnings. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2494) Switch Trinidad Plugin Source Code to use Generics
[ https://issues.apache.org/jira/browse/TRINIDAD-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2494. -- Resolution: Fixed Fix Version/s: 2.1.0-core Resolved in revision 1612454 > Switch Trinidad Plugin Source Code to use Generics > -- > > Key: TRINIDAD-2494 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2494 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Build >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.1.0-core > > Attachments: trinTrunkPlugins-2494_21.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > Switch Trinidad Plugins to use generics, cleaning up warnings. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2494) Switch Trinidad Plugin Source Code to use Generics
Blake Sullivan created TRINIDAD-2494: Summary: Switch Trinidad Plugin Source Code to use Generics Key: TRINIDAD-2494 URL: https://issues.apache.org/jira/browse/TRINIDAD-2494 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 2.1.0-core Reporter: Blake Sullivan Priority: Minor Switch Trinidad Plugins to use generics, cleaning up warnings. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2493) Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin
[ https://issues.apache.org/jira/browse/TRINIDAD-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2493: - Resolution: Fixed Status: Resolved (was: Patch Available) Resolved by patch > Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin > --- > > Key: TRINIDAD-2493 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2493 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Trivial > Attachments: trin2493_on_2_1.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > The UIXIterator hooks processFlattenedChildrenBegin and other UIXCollection > subclasses have similar requirements in order to behave differently if the > UIXCollection is being rendered -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2493) Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin
[ https://issues.apache.org/jira/browse/TRINIDAD-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2493: - Status: Patch Available (was: Open) > Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin > --- > > Key: TRINIDAD-2493 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2493 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Trivial > Original Estimate: 1h > Remaining Estimate: 1h > > The UIXIterator hooks processFlattenedChildrenBegin and other UIXCollection > subclasses have similar requirements in order to behave differently if the > UIXCollection is being rendered -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2493) Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin
Blake Sullivan created TRINIDAD-2493: Summary: Allow subclasses of UIXCollection to hook processFlattenedChildrenBegin Key: TRINIDAD-2493 URL: https://issues.apache.org/jira/browse/TRINIDAD-2493 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Blake Sullivan Priority: Trivial The UIXIterator hooks processFlattenedChildrenBegin and other UIXCollection subclasses have similar requirements in order to behave differently if the UIXCollection is being rendered -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [Trinidad] New API addition for Trinidad's UIXCollection
It should be the same.
— Blake Sullivan
On May 15, 2014, at 7:58 AM, Andrew Robinson
wrote:
> How is this different from just setting the current row index to -1?
>
>
> On Tue, May 6, 2014 at 1:49 PM, Jing Wu wrote:
> Thanks Blake for your comment!
>
> It's the component that is hanging onto a rowkey, the model naturally reacts
> to key change and has valid state. But UIXCollection component caches the key
> in it's internal state object which needs to be cleared out and recalculated.
> So the proposal is to simply provide a hook for module (e.g. a listener that
> listens to key change) to clear out the component's cache. So when next time
> there's need to get the current key from the component, since there's no
> cached value, the component will retrieve it from the model which contains
> the already updated key.
>
>
> Thanks,
> Jing
>
>
> On 5/5/2014 8:33 PM, Blake Sullivan wrote:
> Jing,
>
> What is an example of a case where code external to the model implementation
> knows that:
> 1) The model is hanging onto a rowKey
> 2) The key is invalid
>
> The model implementation is typical supposed to encapsulate this information.
>
> -- Blake Sullivan
>
> On May 5, 2014, at 3:26 PM, Jing Wu wrote:
>
> Hi,
>
> This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471.
>
> UIXCollection caches the current row key in its internal state. There are
> cases that the row key becomes stale / invalid in the middle of processing a
> row. A new API invalidateCurrentRowKey() is added to UIXCollection to clear
> out the cached current row key, so next time when it is requested, this
> current new key will be recalculated from model.
>
>
> /**
>* Invalidate the cached current row key so it will be recalculated
>* from the model next time when it is requested.
>*/
> public void invalidateCurrentRowKey()
> {
> }
>
> Any comment is welcome!
>
> Thanks,
> Jing
>
>
>
Re: [Trinidad] New API addition for Trinidad's UIXCollection
Jing,
What is an example of a case where code external to the model implementation
knows that:
1) The model is hanging onto a rowKey
2) The key is invalid
The model implementation is typical supposed to encapsulate this information.
-- Blake Sullivan
On May 5, 2014, at 3:26 PM, Jing Wu wrote:
> Hi,
>
> This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471.
>
> UIXCollection caches the current row key in its internal state. There are
> cases that the row key becomes stale / invalid in the middle of processing a
> row. A new API invalidateCurrentRowKey() is added to UIXCollection to clear
> out the cached current row key, so next time when it is requested, this
> current new key will be recalculated from model.
>
>
> /**
> * Invalidate the cached current row key so it will be recalculated
> * from the model next time when it is requested.
> */
> public void invalidateCurrentRowKey()
> {
> }
>
> Any comment is welcome!
>
> Thanks,
> Jing
>
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
+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 wrote:
> I'm changing my vote to +1. I was able to fix this issue in the trinidad
> poms by adding:
>
>
>
> org.apache.myfaces.trinidad
> trinidad-api
> ${project.version}
>
>
>
> 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(Gener
Re: [DISCUSS] trinidad.next
I assume that the specific issue is when Trinidad is using the ExternalContext as an api to hide Servlet vs. Portlet differences BEFORE the FacesContext is created. In these cases, Trinidad needs to create concrete ExternalContext implementations for Servlets and Portlets. An example of this are the Configurators that abstract away ServletFilters. Other frameworks may not have tis functionality, but regardless JSF 2.0 and JSF 2.1 have api incompatibilities that I believe are illegal for minor releases. -- Blake Sullivan On Oct 30, 2013, at 4:12 PM, Gerhard Petracek 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 > 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 >> 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
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 > 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: Trinidad tr:commandlink tr:commandbutton
The behavior is implemented by the browser and that is what the browser implements. -- Blake Sullivan On Aug 14, 2013, at 3:31 AM, wrote: > Hi all, > > does anyone one why the accessKey property behaves different for > tr:commandLink and tr:commandButton. > Setting accessKey for tr:commandbuttonàbutton function is called immediately > Setting accesskey for tr:commandlinkàlink is only getting the focus. > > Thanks and regards > Steffen > >
[jira] [Created] (TRINIDAD-2401) Clean up skinning code to avoid use of obsolete synchronized classes
Blake Sullivan created TRINIDAD-2401: Summary: 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 Priority: Minor 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 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-2378) UIXComponentBase should override clearCachedClientId to avoid calling getId() at times when the UIViewRoot isn't present
Blake Sullivan created TRINIDAD-2378: Summary: 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 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 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-2374) UIXComponentBase._calculateClientId should throw exception if the component is not in the tree
Blake Sullivan created TRINIDAD-2374: Summary: UIXComponentBase._calculateClientId should throw exception if the component is not in the tree Key: TRINIDAD-2374 URL: https://issues.apache.org/jira/browse/TRINIDAD-2374 Project: MyFaces Trinidad Issue Type: Bug Reporter: Blake Sullivan If a component is not in the UIViewRoot's component tree when _calculateClientId() is called, we can generate and cache an invalid clientId. Instead, we should throw an IllegalStateException -- 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-2365) Change UIViewRoot caching behavior from per-window to per-session
Blake Sullivan created TRINIDAD-2365: Summary: Change UIViewRoot caching behavior from per-window to per-session Key: TRINIDAD-2365 URL: https://issues.apache.org/jira/browse/TRINIDAD-2365 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.1-core, 2.0.0-core, 2.1.0-core Environment: All Reporter: Blake Sullivan Currently UIViewRoots are cached per-window. This is incredibly expensive. The fix is to change the default caching behavior to be per-session instead, where the one-and-only cached UIViewRoot is the UIViewRoot for the last processed request, regardless of window -- 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-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420916#comment-13420916 ] Blake Sullivan commented on TRINIDAD-2293: -- In the HA case you describe, your solution is forcing the HA system to replicate file A to the failover server just-in-case. This is a huge expense for a very rare case. In this case, the user can simply reupload the file. In addition, it isn't clear how the current code doesn't suffer from race conditions. If we are worried about the file A, file B case you describe, the solution is to run the lifecycle on file A as soon as it completes. This also, conveniently reduces the resource requirements on the server. How does this code handle the case where the user starts an upload from more than one multifile upload in the same page or separate multifile uploads on multiple pages. It seems like we would get clashes on the session keys. Also, does the code correctly handle the case where the server crashed while writing a temp file to disk? > multi file upload does not get replicated in a High Availability environment > > > Key: TRINIDAD-2293 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Infrastructure >Affects Versions: 2.0.2-core > Environment: linux x86 >Reporter: Kentaro Kinebuchi > Attachments: Trinidad-2293.patch > > > In multi file upload, the uploaded files are stored in the user's session > before submit. In a HA environment, the session context which is replicated > does not contain this file information so if the server goes down then the > file data is lost in the replicated server. > There are two specific issues which need to be handled in the code: > 1. In WebLogic, unless the setAttribute() method is called on the session > context, that attribute is not automatically replicated. Hence, all > attributes which are updated during multi file upload and we want replicated > have to specifically call that method. > 2. WebLogic does not replicate all File objects stored in the context. Hence, > the path to the temporary file created for each uploaded file needs to be > saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2293: - Status: Open (was: Patch Available) > multi file upload does not get replicated in a High Availability environment > > > Key: TRINIDAD-2293 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Infrastructure >Affects Versions: 2.0.2-core > Environment: linux x86 >Reporter: Kentaro Kinebuchi > Attachments: Trinidad-2293.patch > > > In multi file upload, the uploaded files are stored in the user's session > before submit. In a HA environment, the session context which is replicated > does not contain this file information so if the server goes down then the > file data is lost in the replicated server. > There are two specific issues which need to be handled in the code: > 1. In WebLogic, unless the setAttribute() method is called on the session > context, that attribute is not automatically replicated. Hence, all > attributes which are updated during multi file upload and we want replicated > have to specifically call that method. > 2. WebLogic does not replicate all File objects stored in the context. Hence, > the path to the temporary file created for each uploaded file needs to be > saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2293) multi file upload does not get replicated in a High Availability environment
[ https://issues.apache.org/jira/browse/TRINIDAD-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420798#comment-13420798 ] Blake Sullivan commented on TRINIDAD-2293: -- There must be something that I am missing because this seems to be solving a problem that does not exist. If I understand things correctly, we only hang onto the uploaded bytes for the duration of the request. If that is the case, then the only case in which we will lose data is if the VM dies during a request. Fail over does not do anything if the server goes down during an in-flight request--the session information is only copied at the end of the request (at the earliest). Similar issues apply to the handling of the temporary file--we shouldn't worry about trying to copy the location over because the user is supposed to retry if the request fails. Also, why are we storing any of this information in the Session? This would seem to cause race conditions If we were going to make UploadedFiles Serializable, we would need a serialVersionUID Why would we be using this code: ((HttpServletRequest) externalContext.getRequest()).getSession().setAttribute(UploadedFiles.UPLOADED_FILES_KEY, sessionFiles); Instead of this code: externalContext.getSessionMap().put(UploadedFiles.UPLOADED_FILES_KEY, sessionFiles); > multi file upload does not get replicated in a High Availability environment > > > Key: TRINIDAD-2293 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2293 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Infrastructure >Affects Versions: 2.0.2-core > Environment: linux x86 >Reporter: Kentaro Kinebuchi > Attachments: Trinidad-2293.patch > > > In multi file upload, the uploaded files are stored in the user's session > before submit. In a HA environment, the session context which is replicated > does not contain this file information so if the server goes down then the > file data is lost in the replicated server. > There are two specific issues which need to be handled in the code: > 1. In WebLogic, unless the setAttribute() method is called on the session > context, that attribute is not automatically replicated. Hence, all > attributes which are updated during multi file upload and we want replicated > have to specifically call that method. > 2. WebLogic does not replicate all File objects stored in the context. Hence, > the path to the temporary file created for each uploaded file needs to be > saved in a String in the context so it is replicated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2288) ClassCastException on XhtmlRenderer.getPartialTriggers
[
https://issues.apache.org/jira/browse/TRINIDAD-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412938#comment-13412938
]
Blake Sullivan commented on TRINIDAD-2288:
--
The getPartialTriggers() code is correct--the type of this attribute is
String[]. The bug is in the code that is setting the a simple String as the
partialTriggers instead of a String[].
> ClassCastException on XhtmlRenderer.getPartialTriggers
> --
>
> Key: TRINIDAD-2288
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2288
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: 1.2.13-core , 1.2.14-core
> Environment: tomcat 7, java 6
>Reporter: Jasper de Vries
>
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlRenderer#getPartialTriggers(org.apache.myfaces.trinidad.bean.FacesBean)
> throws a java.lang.ClassCastException: java.lang.String cannot be cast to
> [Ljava.lang.String (in some cases?).
> I think solved it locally using
> Object property = bean.getProperty(_partialTriggersKey);
> if (property instanceof String)
> return new String[]{ (String)property };
> else
> return (String[])bean.getProperty(_partialTriggersKey);
> Since it involves partial trigger I'm not sure if I need to split the string
> on spaces.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2287) atomicity violation bugs of misusing concurrent collections
[
https://issues.apache.org/jira/browse/TRINIDAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411898#comment-13411898
]
Blake Sullivan commented on TRINIDAD-2287:
--
I haven't looked at all of them yet. It is quite possible that some of these
are over-synchronized.
> atomicity violation bugs of misusing concurrent collections
> ---
>
> Key: TRINIDAD-2287
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2287
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 2.0.1-core
>Reporter: Yu Lin
> Attachments: trinidad-2.0.1.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> My name is Yu Lin. I'm a Ph.D. student in the CS department at
> UIUC. I'm currently doing research on mining Java concurrent library
> misusages. I found some misusages of ConcurrentHashMap in Trinidad
> 2.0.1, which may result in potential atomicity violation bugs or harm
> the performance.
> The code below is a snapshot of the code in file
> trinidad-api/src/main/java/org/apache/myfaces/trinidad/bean/PropertyKey.java
> from line 102 to 112
> L102 PropertyKey cachedKey = _sDefaultKeyCache.get(name);
> L104 if (cachedKey == null)
> L105 {
> L106 cachedKey = new PropertyKey(name);
> L108 // we don't need putIfAbsent because we don't care about identity
> L109 _sDefaultKeyCache.put(name, cachedKey);
> L110 }
> L112 return cachedKey;
> In the code above, an atomicity violation may occur between line 105
> and 109. Suppose a thread T1 executes line 102 and finds out the
> concurrent hashmap does not contain the key "name". Before it gets to
> execute line 109, another thread T2 puts a pair in the
> concurrent hashmap "_sDefaultKeyCache". Now thread T1 resumes
> execution and it will overwrite the value written by thread T2. Thus,
> the code no longer preserves the "put-if-absent" semantics.
> I found some similar atomicity violations in other 17 places (I don't
> list them one by one. Please see the patch).
> Note that in
> trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/cache/Cache.java,
> if we use "putIfAbsent" at line 89 and "replace" at line 115, we may
> remove the synchronized keyword at line 82. Similarly, in
> trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/RenderKitBase.java,
> we may remove the synchronized by using "putIfAbsent" at line 192.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2287) atomicity violation bugs of misusing concurrent collections
[
https://issues.apache.org/jira/browse/TRINIDAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411194#comment-13411194
]
Blake Sullivan commented on TRINIDAD-2287:
--
I don't understand why you think that no preserving put-if-absent semantics is
important. The code says that it explicitly doesn't care about these semantics:
// we don't need putIfAbsent because we don't care about identity
_sDefaultKeyCache.put(name, cachedKey);
Since we don't care about those semantics, put will always perform better than
putIfAbsent
> atomicity violation bugs of misusing concurrent collections
> ---
>
> Key: TRINIDAD-2287
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2287
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 2.0.1-core
>Reporter: Yu Lin
> Attachments: trinidad-2.0.1.patch
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> My name is Yu Lin. I'm a Ph.D. student in the CS department at
> UIUC. I'm currently doing research on mining Java concurrent library
> misusages. I found some misusages of ConcurrentHashMap in Trinidad
> 2.0.1, which may result in potential atomicity violation bugs or harm
> the performance.
> The code below is a snapshot of the code in file
> trinidad-api/src/main/java/org/apache/myfaces/trinidad/bean/PropertyKey.java
> from line 102 to 112
> L102 PropertyKey cachedKey = _sDefaultKeyCache.get(name);
> L104 if (cachedKey == null)
> L105 {
> L106 cachedKey = new PropertyKey(name);
> L108 // we don't need putIfAbsent because we don't care about identity
> L109 _sDefaultKeyCache.put(name, cachedKey);
> L110 }
> L112 return cachedKey;
> In the code above, an atomicity violation may occur between line 105
> and 109. Suppose a thread T1 executes line 102 and finds out the
> concurrent hashmap does not contain the key "name". Before it gets to
> execute line 109, another thread T2 puts a pair in the
> concurrent hashmap "_sDefaultKeyCache". Now thread T1 resumes
> execution and it will overwrite the value written by thread T2. Thus,
> the code no longer preserves the "put-if-absent" semantics.
> I found some similar atomicity violations in other 17 places (I don't
> list them one by one. Please see the patch).
> Note that in
> trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/cache/Cache.java,
> if we use "putIfAbsent" at line 89 and "replace" at line 115, we may
> remove the synchronized keyword at line 82. Similarly, in
> trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/RenderKitBase.java,
> we may remove the synchronized by using "putIfAbsent" at line 192.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [trinidad] javascript documentation using jsdoc
Leonardo,
I'm not sure what you are asking. Are you asking what "prototype" means
in JavaScript? If that is what you are asking, then the quickie answer
is that Javascript uses template-based inheritance. Every JS Object has
a prototype property pointing to the instance that this JS Object will
delegate to. Some JS frameworks simulate class-based inheritance by
creating an instance representing a class and then making that instance
the prototype of all of the instances of that "class". Similarly a
"subclass" would have it's superclass as its prototype.
Putting this together:
function TrPanelPopup()
{
//define object properties
this._content = false;
this._trigger = false;
this._centered = false;
this._modal = false;
this._visible = false;
}
Is a constructor.
new TrPanelPopup() would create an instance of TrPanelPopup.
TrPanelPopup.prototype.getContent = function()
Is assigning the getContent() function to the prototype of instances
created through new TrPanelPopup(). getContent() ends up being similar
to an instance method.
You can also create something like a static method, like so:
TrPanelPopup.staticGetContent = function()
Notice the lack of the prototype. Callers would refer to this method
(var myContent = TrPanelPopup.staticGetContent()) directly rather than
through an instance:
var thePopup = new TrPanelPopup();
var theContent = thePopup.getContent();
-- Blake Sullivan
On 7/5/12 5:59 AM, Leonardo Uribe wrote:
Hi
I tried to add this to trinidad-impl pom.xml:
generate-assembly
org.apache.myfaces.buildtools
myfaces-jsdoc-plugin
1.0-beta-1
attach-jsdoc
jar
It is the same we use in myfaces core to generate javascript doc. The
good news is it works. We could add it as a report to generate it when
the site is build or include it as a jar.
But before do that, we need to add the proper jsdoc annotations.
Unfortunately, I get lost in the pattern used to annotate classes.
Does anybody knows which are the used code conventions in that part?.
For example in TrPanelPopup for example:
function TrPanelPopup()
{
//define object properties
this._content = false;
this._trigger = false;
this._centered = false;
this._modal = false;
this._visible = false;
}
TrPanelPopup.prototype.getContent = function()
What is prototype? the body of the class?.
I think with the work already done to generate the jsdoc in myfaces
core, generate the same info for trinidad is easy, but obviously jsdoc
annotations are a little bit tricky.
regards,
Leonardo Uribe
[jira] [Resolved] (TRINIDAD-2273) Allow scheme for application to control UIViewRoot caching logic
[ https://issues.apache.org/jira/browse/TRINIDAD-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2273. -- Resolution: Fixed > Allow scheme for application to control UIViewRoot caching logic > > > Key: TRINIDAD-2273 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2273 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.12-core, 2.0.1-core > Environment: all > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Fix For: 2.0.0-core > > Attachments: trin_2273_2_1.patch, trin_2273_2_1_part_deux.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > When UIViewRoot caching is enabled, the cached UIViewRoots can consume > considerable memory across all of the users. The proposal is to extend the > allowed values of the Servlet Initialization parameter: > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > to support, in addition to the current "true", and "false" values, the values > of: > "strong" UIViewRoot caching is enabled and always uses strong references to > the cached UIViewRoot > "soft" UIViewRoot caching is enabled and always uses soft references to the > cached UIViewRoot, allowing the cached UIViewRoots to be purged if under > memory pressure > The fully qualified classname of an implementation of > org.apache.myfaces.trinidad.util.ref.PseudoReferenceFactory returning any > desired PseudoReference implementation. > In addition, the value of "true" now uses the value of a > PseudoReferenceFactory implementation registered under the service name > "org.apache.myfaces.trinidad.CACHE_VIEW_ROOT" if one is registered, > otherwise, it uses a strong reference, to duplicate the current functionality -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TRINIDAD-2273) Allow scheme for application to control UIViewRoot caching logic
[ https://issues.apache.org/jira/browse/TRINIDAD-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan reopened TRINIDAD-2273: -- > Allow scheme for application to control UIViewRoot caching logic > > > Key: TRINIDAD-2273 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2273 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.12-core, 2.0.1-core > Environment: all > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Fix For: 2.0.0-core > > Attachments: trin_2273_2_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > When UIViewRoot caching is enabled, the cached UIViewRoots can consume > considerable memory across all of the users. The proposal is to extend the > allowed values of the Servlet Initialization parameter: > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > to support, in addition to the current "true", and "false" values, the values > of: > "strong" UIViewRoot caching is enabled and always uses strong references to > the cached UIViewRoot > "soft" UIViewRoot caching is enabled and always uses soft references to the > cached UIViewRoot, allowing the cached UIViewRoots to be purged if under > memory pressure > The fully qualified classname of an implementation of > org.apache.myfaces.trinidad.util.ref.PseudoReferenceFactory returning any > desired PseudoReference implementation. > In addition, the value of "true" now uses the value of a > PseudoReferenceFactory implementation registered under the service name > "org.apache.myfaces.trinidad.CACHE_VIEW_ROOT" if one is registered, > otherwise, it uses a strong reference, to duplicate the current functionality -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2273) Allow scheme for application to control UIViewRoot caching logic
[ https://issues.apache.org/jira/browse/TRINIDAD-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402671#comment-13402671 ] Blake Sullivan commented on TRINIDAD-2273: -- Reopened because this caused a regression when view root caching was disabled > Allow scheme for application to control UIViewRoot caching logic > > > Key: TRINIDAD-2273 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2273 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.12-core, 2.0.1-core > Environment: all > Reporter: Blake Sullivan >Assignee: Blake Sullivan > Fix For: 2.0.0-core > > Attachments: trin_2273_2_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > When UIViewRoot caching is enabled, the cached UIViewRoots can consume > considerable memory across all of the users. The proposal is to extend the > allowed values of the Servlet Initialization parameter: > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > to support, in addition to the current "true", and "false" values, the values > of: > "strong" UIViewRoot caching is enabled and always uses strong references to > the cached UIViewRoot > "soft" UIViewRoot caching is enabled and always uses soft references to the > cached UIViewRoot, allowing the cached UIViewRoots to be purged if under > memory pressure > The fully qualified classname of an implementation of > org.apache.myfaces.trinidad.util.ref.PseudoReferenceFactory returning any > desired PseudoReference implementation. > In addition, the value of "true" now uses the value of a > PseudoReferenceFactory implementation registered under the service name > "org.apache.myfaces.trinidad.CACHE_VIEW_ROOT" if one is registered, > otherwise, it uses a strong reference, to duplicate the current functionality -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2273) Allow scheme for application to control UIViewRoot caching logic
[ https://issues.apache.org/jira/browse/TRINIDAD-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2273. -- Resolution: Fixed Fix Version/s: 2.0.0-core > Allow scheme for application to control UIViewRoot caching logic > > > Key: TRINIDAD-2273 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2273 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.12-core, 2.0.1-core > Environment: all > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Fix For: 2.0.0-core > > Attachments: trin_2273_2_1.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > When UIViewRoot caching is enabled, the cached UIViewRoots can consume > considerable memory across all of the users. The proposal is to extend the > allowed values of the Servlet Initialization parameter: > org.apache.myfaces.trinidad.CACHE_VIEW_ROOT > to support, in addition to the current "true", and "false" values, the values > of: > "strong" UIViewRoot caching is enabled and always uses strong references to > the cached UIViewRoot > "soft" UIViewRoot caching is enabled and always uses soft references to the > cached UIViewRoot, allowing the cached UIViewRoots to be purged if under > memory pressure > The fully qualified classname of an implementation of > org.apache.myfaces.trinidad.util.ref.PseudoReferenceFactory returning any > desired PseudoReference implementation. > In addition, the value of "true" now uses the value of a > PseudoReferenceFactory implementation registered under the service name > "org.apache.myfaces.trinidad.CACHE_VIEW_ROOT" if one is registered, > otherwise, it uses a strong reference, to duplicate the current functionality -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2278) HttpSession inside a synchronized block in the class TokenCache of trinidad-impl-1.0.10.jar could cause to deadlock while used with WAS 7
[
https://issues.apache.org/jira/browse/TRINIDAD-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401744#comment-13401744
]
Blake Sullivan commented on TRINIDAD-2278:
--
As you guys figured out, this code is working as intended--the requirements are
to:
1) Guarantee that only a single instance of the token cache is created per
session
2) Only lock the current session
We should not change this without more information regarding in what use case
IBM believes that this usage
It is funny that the IBM documentation refers to Java Concurrency in Practice
as the book explicitly talks about how the Servlet Specification is lame
because:
a) It doesn't expose any ConcurrentMaps
b) It doesn't give access to any internal lock object
c) It doesn't document whether external locking is allowed
The upshot is the applications are really left with only one option--sse
external locking and hope for the best (what TokenCache is doing).
There are two other options that might seem appealing, but they have their own
issues:
1) Create a finer-grained Serializable object, store that in the Session and
make sure that all ConcurrentMap-style operations on an attribute lock on that
lock object
This unfortunately has all of the same--How do I avoid creating this lock
object twice problem that we are trying to solve
2) Lock on the SessionMap
Unfortunately, the SessionMap instances may have a many-to-one relationship
with the actual Session object, so this doesn't work
> HttpSession inside a synchronized block in the class TokenCache of
> trinidad-impl-1.0.10.jar could cause to deadlock while used with WAS 7
> -
>
> Key: TRINIDAD-2278
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2278
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.10-core
>Reporter: Reshmi Choudhury
>
> Hi,
> We are using trinidad-impl-1.0.10.jar in our product. I see that HttpSession
> is used in a synchronized block in the class TokenCache of
> trinidad-impl-1.0.10.jar. Could you please clarify if this could cause to
> deadlock while used with WAS 7.
> Please find the below code snippet for your quick reference.
> static public TokenCache getTokenCacheFromSession( FacesContext context,
> String cacheName, boolean createIfNeeded, int defaultSize) {
> ExternalContext external = context.getExternalContext();
> Object session = external.getSession(true);
> assert(session != null);
> TokenCache cache;
> // Synchronize on the session object to ensure that
> // we don't ever create two different caches
> synchronized (session)
> {
> cache = (TokenCache) external.getSessionMap().get(cacheName);
> if ((cache == null) && createIfNeeded)
> {
> // Seed the token cache with the session ID (if available)
> int seed = 0;
> if (_USE_SESSION_TO_SEED_ID)
> {
> if (session instanceof HttpSession)
> {
> String id = ((HttpSession) session).getId();
> if (id != null)
> seed = id.hashCode();
> }
> }
> cache = new TokenCache(defaultSize, seed);
> external.getSessionMap().put(cacheName, cache);
> }
> }
> return cache;
> }
> This information is required as IBM informs the developer not to synchronize
> the session or it will cause deadlocks. WAS 7 implements the Servlets 2.5
> specification and manages the thread safety for any modification to the
> session map. Please refer to the URL
> http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/uprs_rsession_manager.html
> for more details. This URL contains this text:
> “Applications cannot synchronize session objects inside of their servlets or
> Java Server Pages because a deadlock with the session manager may occur. The
> deadlock occurs because the session manager does not expect the use of more
> than one locking mechanism”
> Here is an excellent article on this topic, which explains when explicit
> synchronization is needed in the application code and when the servlet
> container's locking mechanism is sufficient:
> http://www.ibm.com/developerworks/library/j-jtp09238/index.html
>
> It would be really helpful if we receive the information at the earliest as
> this is priority at our end.
> Thanks in advance.
> Regards,
> Reshmi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2273) Allow scheme for application to control UIViewRoot caching logic
Blake Sullivan created TRINIDAD-2273: Summary: Allow scheme for application to control UIViewRoot caching logic Key: TRINIDAD-2273 URL: https://issues.apache.org/jira/browse/TRINIDAD-2273 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core, 1.2.12-core Environment: all Reporter: Blake Sullivan When UIViewRoot caching is enabled, the cached UIViewRoots can consume considerable memory across all of the users. The proposal is to extend the allowed values of the Servlet Initialization parameter: org.apache.myfaces.trinidad.CACHE_VIEW_ROOT to support, in addition to the current "true", and "false" values, the values of: "strong" UIViewRoot caching is enabled and always uses strong references to the cached UIViewRoot "soft" UIViewRoot caching is enabled and always uses soft references to the cached UIViewRoot, allowing the cached UIViewRoots to be purged if under memory pressure The fully qualified classname of an implementation of org.apache.myfaces.trinidad.util.ref.PseudoReferenceFactory returning any desired PseudoReference implementation. In addition, the value of "true" now uses the value of a PseudoReferenceFactory implementation registered under the service name "org.apache.myfaces.trinidad.CACHE_VIEW_ROOT" if one is registered, otherwise, it uses a strong reference, to duplicate the current functionality -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2261) Error serializing the attribute PageState in a clustered enviroment
[ https://issues.apache.org/jira/browse/TRINIDAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263834#comment-13263834 ] Blake Sullivan commented on TRINIDAD-2261: -- It should not matter that the class is private for Serialization. The class should not be made public. > Error serializing the attribute PageState in a clustered enviroment > --- > > Key: TRINIDAD-2261 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2261 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 2.0.0-core > Environment: Tomcat 7 >Reporter: Arsene Costin >Priority: Critical > Attachments: SerialozationProblem.patch > > > The PageState it is Private class and can not be deserialized in a Clustered > Enviroment. We have also attached a patch that contains the modification.The > patch is created from the trunk of the trinidad repository. It will help us a > lot if you will put this in your next release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2248) Change component templating scheme to generate superclasses of templated components rather than the templated components themselves
[
https://issues.apache.org/jira/browse/TRINIDAD-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-2248.
--
Resolution: Fixed
Fix Version/s: 2.0.2-core
Fixed in revision 1304149
> Change component templating scheme to generate superclasses of templated
> components rather than the templated components themselves
> ---
>
> Key: TRINIDAD-2248
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2248
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Build
>Affects Versions: 2.0.1-core
> Reporter: Blake Sullivan
>Assignee: Blake Sullivan
> Fix For: 2.0.2-core
>
> Attachments: trin2248.diff
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> The current component templating scheme works as follows:
> For a component with fully qualified name .
> Look in the parallel java-templates directory tree for the file name>.Template.java
> if it exists, merge the contents of . name>Template.java with the generated class artifacts to create the actual
> component source file ..java.
> On the surface, this seems fine however it has a major impact on
> supportability because
> 1) The .Template.java files often can not be
> included in the IDE projects.
> 2) Debugging of the Template files (which is where all of the interesting
> code is) must be done against the flattened file, which is non-obvious and a
> pain, while the actual fixes need to be done against the Template files
> 3) Each Template file fix requires that the generate-components portion of
> the build be re-executed to reflatten the component
> Developers have tried to work around the first issue in various ways:
> 1) They make the Template extend the superclass of the component to be
> generated, so that the inherited methods are present (this superclass is
> ignored when merging)
> 2) They manually add abstract implementations of any of the artifacts
> generated from metadata, using the bizarre /**/ prefix on the lines to
> indicate to the merging code that the artifact should be ignored when merging
> (to avoid conflicts with the merged functions.
> Even with the hacks, which are a pain to use, more complicated usages with
> inner classes, still can't be supported.
> The proposal is to use real inheritance instead. The old behavior would
> still be supported for backwards compatibility. In the new proposal we:
> Look in the parallel java-templates directory tree for the file name>..java
> if it exists, generate a new package private abstract class file with the
> name .Partial.java containing the generated
> class artifacts.
> The result is that rather that the generated partial class contains all of
> the generated logic and all of the real logic is contained in the component
> developer's class, extending the partial class. The developers class is in
> every way a real class suitable for inclusion in the source control system.
> To convert an old Template.java file to a new name>.java file, the developer:
> 1) Renames the source file
> 2) Changes the old extends and implements to extend just the Partial class
> 3) Adds the constructors of the form:
> /**
>* Construct an instance of the
>*/
> public ()
> {
> super();
> }
> /**
>* Construct an instance of the
>*/
> protected (
> String rendererType
> )
> {
> super(rendererType);
> }
> 4) Deletes any abstract functions added to make the old scheme kind of work
> (these are often preceeded with /**/)
> 5) If you add your own private property keys, you need to create your own
> type and then lock the TYPE yourself. For example:
> public static final FacesBean.Type TYPE = new
> FacesBean.Type(PartialUIXRegion.TYPE);
> private static final PropertyKey _VIEW_ID_INDEX_MAP_KEY =TYPE.registerKey(
> "oracle.adf.view.rich.component.fragment.UIXRegion.viewIdToIndexMap",
> Map.class, null, 0,
> PropertyKey.Mutable.OFTEN);
> static
> {
> TYPE.lock();
> }
> 6) Removes any no longer needed imports
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2248) Change component templating scheme to generate superclasses of templated components rather than the templated components themselves
Change component templating scheme to generate superclasses of templated
components rather than the templated components themselves
---
Key: TRINIDAD-2248
URL: https://issues.apache.org/jira/browse/TRINIDAD-2248
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Build
Affects Versions: 2.0.1-core
Reporter: Blake Sullivan
The current component templating scheme works as follows:
For a component with fully qualified name .
Look in the parallel java-templates directory tree for the file .Template.java
if it exists, merge the contents of .Template.java with the generated class artifacts to create the actual
component source file ..java.
On the surface, this seems fine however it has a major impact on supportability
because
1) The .Template.java files often can not be
included in the IDE projects.
2) Debugging of the Template files (which is where all of the interesting code
is) must be done against the flattened file, which is non-obvious and a pain,
while the actual fixes need to be done against the Template files
3) Each Template file fix requires that the generate-components portion of the
build be re-executed to reflatten the component
Developers have tried to work around the first issue in various ways:
1) They make the Template extend the superclass of the component to be
generated, so that the inherited methods are present (this superclass is
ignored when merging)
2) They manually add abstract implementations of any of the artifacts generated
from metadata, using the bizarre /**/ prefix on the lines to indicate to the
merging code that the artifact should be ignored when merging (to avoid
conflicts with the merged functions.
Even with the hacks, which are a pain to use, more complicated usages with
inner classes, still can't be supported.
The proposal is to use real inheritance instead. The old behavior would still
be supported for backwards compatibility. In the new proposal we:
Look in the parallel java-templates directory tree for the file ..java
if it exists, generate a new package private abstract class file with the name
.Partial.java containing the generated class
artifacts.
The result is that rather that the generated partial class contains all of the
generated logic and all of the real logic is contained in the component
developer's class, extending the partial class. The developers class is in
every way a real class suitable for inclusion in the source control system.
To convert an old Template.java file to a new .java file, the developer:
1) Renames the source file
2) Changes the old extends and implements to extend just the Partial class
3) Adds the constructors of the form:
/**
* Construct an instance of the
*/
public ()
{
super();
}
/**
* Construct an instance of the
*/
protected (
String rendererType
)
{
super(rendererType);
}
4) Deletes any abstract functions added to make the old scheme kind of work
(these are often preceeded with /**/)
5) If you add your own private property keys, you need to create your own type
and then lock the TYPE yourself. For example:
public static final FacesBean.Type TYPE = new
FacesBean.Type(PartialUIXRegion.TYPE);
private static final PropertyKey _VIEW_ID_INDEX_MAP_KEY =TYPE.registerKey(
"oracle.adf.view.rich.component.fragment.UIXRegion.viewIdToIndexMap",
Map.class, null, 0,
PropertyKey.Mutable.OFTEN);
static
{
TYPE.lock();
}
6) Removes any no longer needed imports
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Trinidad 2.0.1 (try 2)
+1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: > +1. > > Thanks for putting this together Scott. > > Andy > > On Feb 24, 2012, at 12:30 PM, Scott O'Bryan wrote: > >> Hi Everyone, >> >> I was running the tasks needed to get the Trinidad 2.0.1 release out and now >> I need a vote as to whether everything looks good or not. I have committed >> most of the most recent submitted patches and things look to be fairly >> stable. There are a few patches outstanding, but I wanted to put those into >> trunk so that they can get some more testing. >> >> This is a very big release with many bug fixes and quite a few fixes to >> support the MyFaces checkstyle audits. You will notice the absence of the >> "component showcase" example module. It was decided to remove this module >> because it contains code brought in by Maven which is NOT under the Apache >> license. The component showcase *IS* available by building the source >> manually. >> >> The last vote was vetoed because some files were missing licenses and there >> were some references to external repositories. The new staging repositories >> contain fixes for all of these issues including an enhancement to the base >> POM file which will automatically run the rat verifications at build to >> prevent the licensing issues in the future. >> >> At this time, I would like to ask for a vote, once again, on this release. >> All of the following should be ready for review: >> >> * The generated repository and assembly artifacts [1] >> * The generated source archive [2] >> * The updated svn repository [3] >> >> Please review the artifacts and vote according to the following: >> >> >> [ ] +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.. >> >> >> This vote will remain open for at least 72 hours. >> >> Thanks, >> Scott O'Bryan >> >> [1] https://repository.apache.org/content/repositories/orgapachemyfaces-067 >> [2] >> https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip >> >> [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/
Re: [VOTE] Release of Trinidad 2.0.1
+1 On 2/21/12 9:18 PM, Scott O'Bryan wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the "component showcase" example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase *IS* available by building the source manually. At this time, I would like to ask for a vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/
[jira] [Resolved] (TRINIDAD-2221) Allow ancestor components to transform and filter ComponentChanges added by their descendants
[
https://issues.apache.org/jira/browse/TRINIDAD-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-2221.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Fixed in revision 1291571 by user "bsullivan".
> Allow ancestor components to transform and filter ComponentChanges added by
> their descendants
> -
>
> Key: TRINIDAD-2221
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2221
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.0.0-beta-2
>Reporter: Blake Sullivan
>Assignee: Blake Sullivan
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: jira2221Main.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Components currently directly add changes to the ChangeManager. This causes
> issues with composition, where an ancestor may wish to modify the behavior of
> its implementation children. The proposal is to add new protected and public
> apis to UIXComponentBase:
> /**
>* Adds a change for a Component, or the Component's subtree, returning the
> change actually added,
>* or null, if no change was added. The proposed change may
> be rejected by the
>* component itself, one of its ancestors, or the ChangeManager
> implementation.
>* @param change The change to add for this component
>* @return The ComponentChange actually added, or
>* null if no change was added.
>*/
> public final ComponentChange addComponentChange(ComponentChange change)
> {
> return addComponentChange(this, change);
> }
> /**
>* Called when adding a change to a Component, or the Component's subtree.
>* The default implementation delegates the call to the parent, if
> possible, otherwise
>* it adds the change to the ChangeManager directly.
>* Subclasses can override this method to among other things, filter or
> transform the changes.
>* @param component The component that the change is for
>* @param change The change to add for this component
>* @return The ComponentChange actually added, or
>* null if no change was added.
>*/
> protected ComponentChange addComponentChange(UIComponent component,
> ComponentChange change)
> The also make the current addAttributeChange a convenience function:
> /**
>* Convenience function for
>* addComponentChange(new AttributeComponentChange(attributeName,
> attributeValue));
>* This function is not final for backwards compatibility
> reasons, however,
>* existing subclassers whould override addComponentChange
> instead.
>* @param attributeName
>* @param attributeValue
>* @see #addComponentChange(UIComponent, ComponentChange)
>*/
> protected void addAttributeChange(
> String attributeName,
> Object attributeValue)
> {
> addComponentChange(new AttributeComponentChange(attributeName,
> attributeValue));
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2221) Allow ancestor components to transform and filter ComponentChanges added by their descendants
[
https://issues.apache.org/jira/browse/TRINIDAD-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212306#comment-13212306
]
Blake Sullivan commented on TRINIDAD-2221:
--
I forgot to add that this requires that existing code that adds changes to
components directly, switch to calling the new public or protected version of
addComponentChange() for this to work.
> Allow ancestor components to transform and filter ComponentChanges added by
> their descendants
> -
>
> Key: TRINIDAD-2221
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2221
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.0.0-beta-2
>Reporter: Blake Sullivan
>Assignee: Blake Sullivan
>Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Components currently directly add changes to the ChangeManager. This causes
> issues with composition, where an ancestor may wish to modify the behavior of
> its implementation children. The proposal is to add new protected and public
> apis to UIXComponentBase:
> /**
>* Adds a change for a Component, or the Component's subtree, returning the
> change actually added,
>* or null, if no change was added. The proposed change may
> be rejected by the
>* component itself, one of its ancestors, or the ChangeManager
> implementation.
>* @param change The change to add for this component
>* @return The ComponentChange actually added, or
>* null if no change was added.
>*/
> public final ComponentChange addComponentChange(ComponentChange change)
> {
> return addComponentChange(this, change);
> }
> /**
>* Called when adding a change to a Component, or the Component's subtree.
>* The default implementation delegates the call to the parent, if
> possible, otherwise
>* it adds the change to the ChangeManager directly.
>* Subclasses can override this method to among other things, filter or
> transform the changes.
>* @param component The component that the change is for
>* @param change The change to add for this component
>* @return The ComponentChange actually added, or
>* null if no change was added.
>*/
> protected ComponentChange addComponentChange(UIComponent component,
> ComponentChange change)
> The also make the current addAttributeChange a convenience function:
> /**
>* Convenience function for
>* addComponentChange(new AttributeComponentChange(attributeName,
> attributeValue));
>* This function is not final for backwards compatibility
> reasons, however,
>* existing subclassers whould override addComponentChange
> instead.
>* @param attributeName
>* @param attributeValue
>* @see #addComponentChange(UIComponent, ComponentChange)
>*/
> protected void addAttributeChange(
> String attributeName,
> Object attributeValue)
> {
> addComponentChange(new AttributeComponentChange(attributeName,
> attributeValue));
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2221) Allow ancestor components to transform and filter ComponentChanges added by their descendants
Allow ancestor components to transform and filter ComponentChanges added by
their descendants
-
Key: TRINIDAD-2221
URL: https://issues.apache.org/jira/browse/TRINIDAD-2221
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-2
Reporter: Blake Sullivan
Assignee: Blake Sullivan
Priority: Minor
Components currently directly add changes to the ChangeManager. This causes
issues with composition, where an ancestor may wish to modify the behavior of
its implementation children. The proposal is to add new protected and public
apis to UIXComponentBase:
/**
* Adds a change for a Component, or the Component's subtree, returning the
change actually added,
* or null, if no change was added. The proposed change may be
rejected by the
* component itself, one of its ancestors, or the ChangeManager
implementation.
* @param change The change to add for this component
* @return The ComponentChange actually added, or
* null if no change was added.
*/
public final ComponentChange addComponentChange(ComponentChange change)
{
return addComponentChange(this, change);
}
/**
* Called when adding a change to a Component, or the Component's subtree.
* The default implementation delegates the call to the parent, if possible,
otherwise
* it adds the change to the ChangeManager directly.
* Subclasses can override this method to among other things, filter or
transform the changes.
* @param component The component that the change is for
* @param change The change to add for this component
* @return The ComponentChange actually added, or
* null if no change was added.
*/
protected ComponentChange addComponentChange(UIComponent component,
ComponentChange change)
The also make the current addAttributeChange a convenience function:
/**
* Convenience function for
* addComponentChange(new AttributeComponentChange(attributeName,
attributeValue));
* This function is not final for backwards compatibility
reasons, however,
* existing subclassers whould override addComponentChange
instead.
* @param attributeName
* @param attributeValue
* @see #addComponentChange(UIComponent, ComponentChange)
*/
protected void addAttributeChange(
String attributeName,
Object attributeValue)
{
addComponentChange(new AttributeComponentChange(attributeName,
attributeValue));
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad] RequestContext.Accessibility.valueOfAlias() API
I also just double-checked the Enum javadoc because I was curious which of the following was expected for Enum foo foo == Enum.valueOf(foo.getClass(), foo.toString()) or foo == Enum.valueOf(foo.getClass(), foo.name()) It is actually the second of these, so everything is good. -- Blake On 2/14/12 9:18 AM, Andy Schwartz wrote: On Tue, Feb 14, 2012 at 11:33 AM, Blake Sullivan wrote: I would go with valueOfDisplayName(). I would actually add a displayName() as well, just like we have name(). Sounds good, will do. I am not a fan of assuming that toString() == displayName() Er... two options here: 1. Leave toString() documentation/contract intentionally vague. 2. Document the current behavior (toString() == displayName()) as the spec'ed/required behavior. I was leaning towards #2 since folks out there might be relying on the existing toString() behavior - ie. we could enshrine this as required behavior in our contract. Do you prefer #1? Andy
Re: [Trinidad] RequestContext.Accessibility.valueOfAlias() API
I prefer #1. If the caller really cares about what she gets, she can call the explicit method. -- Blake Sullivan On 2/14/12 9:18 AM, Andy Schwartz wrote: On Tue, Feb 14, 2012 at 11:33 AM, Blake Sullivan wrote: I would go with valueOfDisplayName(). I would actually add a displayName() as well, just like we have name(). Sounds good, will do. I am not a fan of assuming that toString() == displayName() Er... two options here: 1. Leave toString() documentation/contract intentionally vague. 2. Document the current behavior (toString() == displayName()) as the spec'ed/required behavior. I was leaning towards #2 since folks out there might be relying on the existing toString() behavior - ie. we could enshrine this as required behavior in our contract. Do you prefer #1? Andy
Re: [Trinidad] RequestContext.Accessibility.valueOfAlias() API
I would go with valueOfDisplayName(). I would actually add a displayName() as well, just like we have name(). I am not a fan of assuming that toString() == displayName() -- Blake Sullivan On 2/14/12 4:21 AM, Andy Schwartz wrote: Thanks for the comments guys. On Mon, Feb 13, 2012 at 11:51 PM, Blake Sullivan wrote: Overloaded how? The other question is that we want to be able to go from the displayName->Enum Actually, this is the only question. :-) We've already got an "accessor" - the Accessibility enum overrides toString() to return the display name/pretty name/alias that gets passed in when the constant is created. What I need is a way to map back from the toString() value to the corresponding enum constant. For this, we should follow the pattern set by Enum.valueOf(). So, we'll want something like: Accessibility.valueOfTheStringThatGetsReturnedFromToStringNotTheEnumConstantName() But shorter. Maybe: - valueOfDisplayName()? Or... - valueOfAlias()? Whatever name we come up with, I will: - Update the name of the Accessibility enum constant constructor argument to match. - Add javadoc to toString() that clarifies that it returns the display name/alias/whatever we call it. Andy
Re: [Trinidad] RequestContext.Accessibility.valueOfAlias() API
Overloaded how? The other question is that we want to be able to go from the displayName->Enum -- Blake Sullivan On 2/13/12 8:44 PM, Scott O'Bryan wrote: How would this differ from an overloaded toString()? By contract, that can be overloaded to make more sense. Scott Sent from my iPad On Feb 13, 2012, at 9:27 PM, Blake Sullivan <mailto:blake.sulli...@oracle.com>> wrote: This example <http://www.basilv.com/psd/blog/2006/advanced-uses-of-java-5-enums>uses getDisplayName(), though given the presence of name(), I think displayName() makes more sense (Josh Bloch hates the getXXX(), setXXX() pattern) -- Blake Sullivan On 2/13/12 7:23 PM, Andy Schwartz wrote: Gang - For this newly logged issue: TRINIDAD-2215 String -> Accessibility enum API https://issues.apache.org/jira/browse/TRINIDAD-2215 I would like to add a new valueOfAlias() method to RequestContext.Accessibility, as shown here: https://issues.apache.org/jira/secure/attachment/12514439/trinidad-2215.patch This serves a similar purpose to good old Enum.valueOf(), but operates on the pretty names/aliases used by the Accessibility enum. Any concerns about this? Or suggestions for a better method name? Andy
Re: [Trinidad] RequestContext.Accessibility.valueOfAlias() API
This example <http://www.basilv.com/psd/blog/2006/advanced-uses-of-java-5-enums>uses getDisplayName(), though given the presence of name(), I think displayName() makes more sense (Josh Bloch hates the getXXX(), setXXX() pattern) -- Blake Sullivan On 2/13/12 7:23 PM, Andy Schwartz wrote: Gang - For this newly logged issue: TRINIDAD-2215 String -> Accessibility enum API https://issues.apache.org/jira/browse/TRINIDAD-2215 I would like to add a new valueOfAlias() method to RequestContext.Accessibility, as shown here: https://issues.apache.org/jira/secure/attachment/12514439/trinidad-2215.patch This serves a similar purpose to good old Enum.valueOf(), but operates on the pretty names/aliases used by the Accessibility enum. Any concerns about this? Or suggestions for a better method name? Andy
[jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not work with 2 clicks that post
[
https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188041#comment-13188041
]
Blake Sullivan commented on TRINIDAD-2194:
--
Reverted changes to branch 1.2.12.6.2 in revision 1232592
> Trinidad PPR blocking does not work with 2 clicks that post
> ---
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
>Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch,
> escalatedCustPPRBlocking1.2.12.3.patch,
> escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a
> ppr request is sent to server. This is done via "onclick" attachEvent
> handler(_pprConsumeFirstClick) on the document. The problem is that
> attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way
> to set up an event handler at the capture phase. In this case the AJAX
> requests are initiated by the "onclick" event handler on the link. Since the
> click event listener is at target phase, it is always invoked first. So here
> is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is
> queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which
> setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the
> second click. We can start immediately since we are letting the first event
> pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set
> focus on the blocking div.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2197) _threadLocals in ThreadLocalUtils has a potential of unbound growth
[ https://issues.apache.org/jira/browse/TRINIDAD-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2197. -- Resolution: Fixed Fix Version/s: 2.0.0-core Remove the WeakReferecen from the list if the ThreadLocal has been gc'ed Resolved in 1229700 > _threadLocals in ThreadLocalUtils has a potential of unbound growth > --- > > Key: TRINIDAD-2197 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2197 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.13-core , 2.0.0-core >Reporter: Stevan Malesevic >Assignee: Blake Sullivan > Fix For: 2.0.0-core > > Original Estimate: 1h > Remaining Estimate: 1h > > _threadLocals collection inside of ResettableThreadLocalManager can grow > unbounded in size if application is creating dynamic ThreadLocals -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not work with 2 clicks that post
[
https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181667#comment-13181667
]
Blake Sullivan commented on TRINIDAD-2194:
--
Resolved in trunk in revision 1228484
Resolved in 1.2.12.6.2 in revision 1228488
> Trinidad PPR blocking does not work with 2 clicks that post
> ---
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
>Reporter: Venkata Guddanti
> Attachments: escalatedCustPPRBlocking.patch,
> escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a
> ppr request is sent to server. This is done via "onclick" attachEvent
> handler(_pprConsumeFirstClick) on the document. The problem is that
> attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way
> to set up an event handler at the capture phase. In this case the AJAX
> requests are initiated by the "onclick" event handler on the link. Since the
> click event listener is at target phase, it is always invoked first. So here
> is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is
> queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which
> setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the
> second click. We can start immediately since we are letting the first event
> pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set
> focus on the blocking div.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2180) Deprecate invokeOnComponent in favor of visitTree
[ https://issues.apache.org/jira/browse/TRINIDAD-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2180. -- Resolution: Fixed Fix Version/s: 2.0.2-core Fixed in revision 1220875 > Deprecate invokeOnComponent in favor of visitTree > - > > Key: TRINIDAD-2180 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2180 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Components >Affects Versions: 2.0.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Fix For: 2.0.2-core > > Attachments: jira2176_20.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > a partial visit using visitTree is always at least as fast as > invokeOnComponent. In addition, for components controlling visiting, > providing both invokeOnComponent and visitTree implementations is a source of > errors. The solution is to: > 1) Deprecate invokeOnComponent in UIXComponent > 2) Provide a default implementation in UIXComponent, calling visitTree to > visit the clientId > 3) Remove all overrides of invokeOnComponent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2180) Deprecate invokeOnComponent in favor of visitTree
Deprecate invokeOnComponent in favor of visitTree - Key: TRINIDAD-2180 URL: https://issues.apache.org/jira/browse/TRINIDAD-2180 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0-core Reporter: Blake Sullivan a partial visit using visitTree is always at least as fast as invokeOnComponent. In addition, for components controlling visiting, providing both invokeOnComponent and visitTree implementations is a source of errors. The solution is to: 1) Deprecate invokeOnComponent in UIXComponent 2) Provide a default implementation in UIXComponent, calling visitTree to visit the clientId 3) Remove all overrides of invokeOnComponent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2176) Switch use of Bean.isDesignTime() to use Agent Capabilities
[ https://issues.apache.org/jira/browse/TRINIDAD-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan resolved TRINIDAD-2176. -- Resolution: Fixed Fix Version/s: 2.0.2-core Resolved in revision 1211067 Removed Beans.isDesignTime() Added RenderingContext.isDesignTime() Replaced internal JDEV-specific capability keys with CAP_VE that contains the name of the visual editor being used > Switch use of Bean.isDesignTime() to use Agent Capabilities > --- > > Key: TRINIDAD-2176 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2176 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Archetype >Affects Versions: 2.0.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Fix For: 2.0.2-core > > Attachments: jira2176_20.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Trinidad uses the static Beans.isDesignTime() to determine when a particular > request should generate content based differently because the execution is > occurring within a visual editor. The improvement switches almost all of the > calls to use a capability on the Agent making the request to determine > whether this particular request should execute as if inside of a visual > editor. Among other things, this allows a IDE to support both a visual > editor view and a preview. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2176) Switch use of Bean.isDesignTime() to use Agent Capabilities
[ https://issues.apache.org/jira/browse/TRINIDAD-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2176: - Status: Patch Available (was: Open) > Switch use of Bean.isDesignTime() to use Agent Capabilities > --- > > Key: TRINIDAD-2176 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2176 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Archetype >Affects Versions: 2.0.0-core > Reporter: Blake Sullivan > Assignee: Blake Sullivan > Attachments: jira2176_20.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Trinidad uses the static Beans.isDesignTime() to determine when a particular > request should generate content based differently because the execution is > occurring within a visual editor. The improvement switches almost all of the > calls to use a capability on the Agent making the request to determine > whether this particular request should execute as if inside of a visual > editor. Among other things, this allows a IDE to support both a visual > editor view and a preview. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2176) Switch use of Bean.isDesignTime() to use Agent Capabilities
Switch use of Bean.isDesignTime() to use Agent Capabilities --- Key: TRINIDAD-2176 URL: https://issues.apache.org/jira/browse/TRINIDAD-2176 Project: MyFaces Trinidad Issue Type: Improvement Components: Archetype Affects Versions: 2.0.0-core Reporter: Blake Sullivan Trinidad uses the static Beans.isDesignTime() to determine when a particular request should generate content based differently because the execution is occurring within a visual editor. The improvement switches almost all of the calls to use a capability on the Agent making the request to determine whether this particular request should execute as if inside of a visual editor. Among other things, this allows a IDE to support both a visual editor view and a preview. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] extend maximum allowed line length from 120 to 160
I personally find 120 characters to be the best balance. On the bright side, I expect that once we can use the diamond operator in JDK 7, the pressure for longer lines will decrease. -- Blake Sullivan On 10/28/11 10:33 AM, Gerhard Petracek wrote: @80: -1! @rest: +0 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/28 Volker Weber mailto:v.we...@inexso.de>> Hi Mark, 2011/10/28 Mark Struberg mailto:strub...@yahoo.de>>: > Volker, source code is no newspaper. just wanted to support the statement of easier reading in smaller columns, of cause code is no newspaper, but it still need easy reading. I don't like to scroll left and right to read the code, and even at work were i got the widest screen the 1920px did not suffice to see more than 120 characters with the project and structure sidebars left and right, which i would not like to miss. Regards, Volker > > Imo 80 chars is definitely fine for C or perl with cryptic syntax (programmed that myself for 20 years) but it's not nice for languages where descriptive variable and method names are 'socially accepted' ;) > > > LieGrue, > strub > > > > - Original Message - >> From: Volker Weber mailto:v.we...@inexso.de>> >> To: MyFaces Development mailto:dev@myfaces.apache.org>>; Mark Struberg mailto:strub...@yahoo.de>> >> Cc: >> Sent: Friday, October 28, 2011 9:22 AM >> Subject: Re: [VOTE] extend maximum allowed line length from 120 to 160 >> >> Hi, >> >> -1. >> >> In my opinion 160 characters is much to wide, the current 120 is not >> the preferred, but the allowed max width. >> I vote for 80 characters as preferred max width. >> >> In general reading is easier if the text is not too wide, thats why >> newspaper articles are layouted in columns. >> >> >> Regards, >> Volker >> >> 2011/10/26 Mark Struberg mailto:strub...@yahoo.de>>: >>> Hi! >>> >>> Currently we have really long and very descriptive variable names in >> MyFaces. >>> >>> I personally like that, but due to that we are really often exceeding the >> 120 character per line. >>> >>> Thus my question: should we extend this from 120 to 160 characters being >> allowed per line? >>> >>> [+1] yup make 160 the max default >>> [0] don't care >>> [-1] nope, let's stick with 120 >>> >>> open for 72h ... >>> >>> >>> Please make use of your vote, because I will activate the checkstyle checks >> soon ;) >>> >>> here is my +1. >>> >>> LieGrue, >>> strub >>> >>> >> >> >> >> -- >> inexso - information exchange solutions GmbH >> Ofener Str. 30 | 26121 Oldenburg >> Tel.: +49 441 219 730 56 | >> FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de <mailto:volker.we...@inexso.de> >> >> Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 >> Geschäftsführer: Stefan Schulte, Michael Terschüren >> > -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de <mailto:volker.we...@inexso.de> Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
Re: [jira] [Created] (PORTLETBRIDGE-221) Add explicit exclusions for trinidad in 329 branch
On 10/20/11 2:13 PM, Michael Freedman (Created) (JIRA) wrote: Add explicit exclusions for trinidad in 329 branch --- Key: PORTLETBRIDGE-221 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-221 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0 Reporter: Michael Freedman Assignee: Michael Freedman We are running into problems with a user of the 329 branch codeline when using with extra Faces (componentkit) extensions. The problem is the bridge is updating the bridge scope at the end of the render request pushing all new attributes created during the render into the scope. These extensions are expecting this so numerous request scope attrs which are "flags" that something is initialized/done are inappropriately being carried forward and used causing malfunctions. At the moment we don't want to just blanket reverse the code from saving the scope at the end of the render -- instead deciding the safest thing is to just exclude the specific packages that might exist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira I don't know why we wouldn't blanket reverse this change made in PORTLEETBRIDGE-221. The current bridge behavior is causing request-scoped attributes to live longer than a request. This appears to violate the spirit of section 5.1.2 of the bridge specification: "Specifically, the bridge must implement a notion of a bridge request scope that supplies the expected Faces semantics." And the letter of the specification: "Upon completion of each portlet render, do not preserve any changes in the request scope back into the bridge request scope except those related to internal bridge operations (e.g. VIEW_STATE_PARAM management). In the portlet (and Faces) model, render is supposed to be idempotent." -- Blake Sullivan
Re: [trinidad] cleanup
I agree that we want to get rid of the impl stuff first, but even more important would be to get rid of the last of the old UIX-based renderers and the image generation code that we don't use. -- Blake Sullivan On 10/5/11 6:18 AM, Scott O'Bryan wrote: Yeah, I'm not sure we know what third parties might depend on. I can tell you, for instance, which deprications, for instance, ADFFaces depends on. I can even remove those dependencies. But the nature of Trinidad and client's like ADFFaces is that the Trinidad implementations are exposed to end-users. Further, we've marked things as depricated if there is other functionality in JSF2 which replaces it. There have been some refactorings of API's which might provide "safer", "faster", or "more correct" implementations of certain functionality. That's not to say the old functions are wrong or that existing applications which use them cannot get away with using the old API's, it just means they SHOULD use the new implementations if they want to be "clean" and fully correct. I use the Java Date object as an example. It's an utterly ridiculous class, admittedly, but it works and is there for backward compatibility. There are much more "correct" implementations which address more issues such as different calendars and localization, but that does not make the date object.. "wrong". Trinidad has, in the past, removed or changed API's that just plain didn't work, but I'm not sure that's what we're talking about here. And certainly, I'm cool with removing the deprecated stuff from impl since nobody should be depending on it anyway. My concern is for end users of Trinidad and ADFFaces who may not have a voice or resources to monitor changes of this sort in the Trinidad developer community. I don't know, what do other people think? This is one of those things where I think the more voices the better. Scott On 10/05/2011 06:46 AM, Mark Struberg wrote: My intention is not to break something, and I was ONLY talking about the JSF-2 version of Trinidad. If there is code which just makes no sense at all in JSF-2, then we should in MY opinion kill this code. If it doesn't make sense for Trinidad, then it is highly likely that it also don't make sense for ADF anymore, right? IF some parts are still needed by some known 3rd party libs, then those parts can of course remain. But at the end of the day maintaining Trinidad will become more and more problematic if we don't get rid of long time obsolete stuff. Again: only my personal opinion and experience. I assume that ADF also has a JSF-1 and a separate JSF-2 branch. All the JSF-1 stuff would of course remain the way it is currently! LieGrue, strub - Original Message - From: Scott O'Bryan To: dev@myfaces.apache.org Cc: Sent: Wednesday, October 5, 2011 2:20 PM Subject: Re: [trinidad] cleanup We could, yes. But we would force people to migrate apps which, perhaps is not a bad thing but traditionally we've taken a full vote before changing/removing API's in Trinidad because, doing so, incurs additional cost on the other frameworks which are using Trinidad as a foundation. Any company which provides Trinidad as a foundation for other framework code (like Oracle's ADFFaces) benefits from NOT breaking users of the framework every release and, frankly, I see a lot of value in keeping them around 'if possible'. Like I say, I'm not opposed to it, but I suppose I take more of a Java ZEN approach to deprecation of API's. Scott On 10/05/2011 05:41 AM, Mark Struberg wrote: I'm not sure if I understand this correctly. Trinidad-2 is for JSF-2 upwards exclusively, isn't? If so, then we can easily get rid of all the old dust which just confuses people. Furthermore there seems to be a few compat problems with JSF-2 f:ajax which can only be resolved by carefully cleaning those areas up. Just leave behind the old stuff. LieGrue, strub From: Scott O'Bryan To: MyFaces Development Sent: Wednesday, October 5, 2011 1:06 PM Subject: Re: [trinidad] cleanup Well just because something is depth aged doesn't mean we can remove it. It just means that an alternate means is suggested or something may not work exactly as expected if used. A Prime example is ExternalContextUtils. That guy has been around since JSF 1.1. It contains lots of functionality that wasn't present in later versions of JSF, but now is. Use of the native objects should be encouraged, but there is also something to be said about older code being able to migrate easier to a later release. Now I DO agree with removing the JSDoc and possibly the deprecations in the impl, but I think it's important to k
Re: [jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
The definition is meant to be kept current. The definition is logically the least-common-denominator of the current set of desktop browsers back to IE7. If IE7 or some of the early versions of Safari were no longer setting the lower bar of capability, the capabilities would increase. -- Blake Sullivan On 9/27/11 11:32 AM, Scott O'Bryan wrote: -1 to timescale. In my experience, things that REQUIRE maintenance do not work well in OS.. Scott On 09/27/2011 12:28 PM, Matt Cooper wrote: I'm okay with "genericDesktop". Perhaps this isn't a concern but I wonder if there is any value in giving any sort of time scale for this, e.g. genericDesktop2010 or genericDesktopHtml4, etc. as I presume in 2020 it'll be (I really hope so) nearly impossible to find an HTML display engine that doesn't display HTML5 markup at which point HTML5 will be considered "generic". Thanks, Matt On Tue, Sep 27, 2011 at 12:12 PM, Pavitra Subramaniam <mailto:pavitra.subraman...@oracle.com>> wrote: On 9/27/2011 10:37 AM, Blake Sullivan (Commented) (JIRA) wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115738#comment-13115738 <https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115738#comment-13115738> ] Blake Sullivan commented on TRINIDAD-2141: -- This isn't a generic agent (the 'unknown' agent is actually the 'most generic'), it is a generic, fairly rich desktop agent. I might go for genericDesktop. +1. I prefer the lower camelcase 'genericDesktop" to "genericdesktop", but it looks like the convention used differs - we already have a 'genericpda' / "nokia_s60" etc Thanks Pavitra add a new 'browser-generic' agent -- Key: TRINIDAD-2141 URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 Project: MyFaces Trinidad Issue Type: Improvement Components: Infrastructure Affects Versions: 1.2.15-core , 2.0.1-core Reporter: Pavitra Subramaniam Attachments: JIRA2141.patch It would be very useful to have an agent called - 'browser-generic', which represents the lowest common denominator agent for all browsers. We also would want this to have its own capabilities that any generic browser agent supports today. This agent would be very useful in usecases where the user agent cannot be determined at the time of rendering. For example when rendering content for a page to be used as a file attachment in an email, this could be very useful. CSS rules with @agent keyword would be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa <https://issues.apache.org/jira/secure/ContactAdministrators%21default.jspa> For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
Actually, that's because the committer who checked those in, did so with no public review. -- Blake Sullivan On 9/27/11 11:12 AM, Pavitra Subramaniam wrote: On 9/27/2011 10:37 AM, Blake Sullivan (Commented) (JIRA) wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115738#comment-13115738 ] Blake Sullivan commented on TRINIDAD-2141: -- This isn't a generic agent (the 'unknown' agent is actually the 'most generic'), it is a generic, fairly rich desktop agent. I might go for genericDesktop. +1. I prefer the lower camelcase 'genericDesktop" to "genericdesktop", but it looks like the convention used differs - we already have a 'genericpda' / "nokia_s60" etc Thanks Pavitra add a new 'browser-generic' agent -- Key: TRINIDAD-2141 URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 Project: MyFaces Trinidad Issue Type: Improvement Components: Infrastructure Affects Versions: 1.2.15-core , 2.0.1-core Reporter: Pavitra Subramaniam Attachments: JIRA2141.patch It would be very useful to have an agent called - 'browser-generic', which represents the lowest common denominator agent for all browsers. We also would want this to have its own capabilities that any generic browser agent supports today. This agent would be very useful in usecases where the user agent cannot be determined at the time of rendering. For example when rendering content for a page to be used as a file attachment in an email, this could be very useful. CSS rules with @agent keyword would be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
[ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115738#comment-13115738 ] Blake Sullivan commented on TRINIDAD-2141: -- This isn't a generic agent (the 'unknown' agent is actually the 'most generic'), it is a generic, fairly rich desktop agent. I might go for genericDesktop. > add a new 'browser-generic' agent > -- > > Key: TRINIDAD-2141 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Infrastructure >Affects Versions: 1.2.15-core , 2.0.1-core >Reporter: Pavitra Subramaniam > Attachments: JIRA2141.patch > > > It would be very useful to have an agent called - 'browser-generic', which > represents the lowest common denominator agent for all browsers. > We also would want this to have its own capabilities that any generic browser > agent supports today. > This agent would be very useful in usecases where the user agent cannot be > determined at the time of rendering. > For example when rendering content for a page to be used as a file attachment > in an email, this could be very useful. > CSS rules with @agent keyword would be ignored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent
[ https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106942#comment-13106942 ] Blake Sullivan commented on TRINIDAD-2141: -- Trinidad already has a generic agent. However that agent is the least common denominator of all possible agents and therefore is too weak. I think that this proposal is to support a generic relatively powerful agent. > add a new 'browser-generic' agent > -- > > Key: TRINIDAD-2141 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2141 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Archetype >Reporter: Pavitra Subramaniam > Fix For: 1.2.14-plugins > > > It would be very useful to have an agent called - 'browser-generic', which > represents the lowest common denominator agent for all browsers. > We also would want this to have its own capabilities that any generic browser > agent supports today. > This agent would be very useful in usecases where the user agent cannot be > determined at the time of rendering. > For example when rendering content for a page to be used as a file attachment > in an email, this could be very useful. > Any CSS rules with no @agent keyword would be ignored. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1395) Trinidad does not work with T-Online Browser
[
https://issues.apache.org/jira/browse/TRINIDAD-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073063#comment-13073063
]
Blake Sullivan commented on TRINIDAD-1395:
--
Or the less verbose:
if (theExternal && theExternal.AutoCompleteSaveForm)
> Trinidad does not work with T-Online Browser
>
>
> Key: TRINIDAD-1395
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1395
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 1.2.10-core
>Reporter: Jürgen Kofler
>Assignee: Matthias Weßendorf
>Priority: Minor
> Fix For: 1.2.12-core
>
>
> T-Online is a german ISP that ships its own web browser. Despite this browser
> is based on IE 7 it does not work with Trinidad:
> submitForm() in Core.js and sendFormPost() and _doRequestThroughIframe() in
> RequestQueue.js fail because window.external.AutoCompleteSaveForm() is not
> definied within this browser. That might have to do with their own
> autocomplete implementation. Anyway, a possible fix that works for us is to
> surround the function call by a try-catch:
> if(_agent.isIE && window.external) {
> try {
> window.external.AutoCompleteSaveForm(a0);
> } catch(e) {}
> }
> T-Online Browser: http://service.t-online.de/c/12/70/32/96/12703296.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
Don't we want something like "none" for the case where no support is
available?
-- Blake Sullivan
On 6/13/11 4:17 PM, Andrew Robinson (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048868#comment-13048868
]
Andrew Robinson commented on TRINIDAD-2108:
---
static public final CapabilityKey CAP_TOUCH_SCREEN =
CapabilityKey.getCapabilityKey("touchScreen", true);
This capability would return null, "single" or "multiple" indicating no touch
support, one finger or multiple simultaneous touches.
Add touch capability to the agent API to be able to determine agents that are
touch screen based.
-
Key: TRINIDAD-2108
URL: https://issues.apache.org/jira/browse/TRINIDAD-2108
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.1
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Minor
There is currently no means to tell from the Agent that it has a touch screen
or not to know if a component may need to use touch* events on the client as
opposed to mouse* events. It would be nice to have such a capability for
identifying Android and iOS as touch screen devices.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [TRINIDAD] Supporting touch capability
I think we should have one per device and we might eventually want to
support some keyboard-related ones as well to include differences
between real and various on-screen keyboards.
-- Blake Sullivan
On 6/13/11 10:52 AM, Andrew Robinson wrote:
We could have it return constant strings of "none", "single" and
"multiple" if that would suit our needs.
So my question is if we want one capability per-human interaction
device or multiple?
Option 1, one-per:
1. touchScreen capability
2. mouse capability
3. drawingPad capability
Option 2, one that returns a set
"interactionDevices" capability with "touchScreen", "mouse",
"drawingPad", etc.
If using the former, we could have strings returned and not boolean
(touchScreen could return "multiTouch", "singleTouch"). Not sure how
that would look for option 2 other than a Map being
returned, but that API seems a bit ugly to me with having to down-cast
the capability value to a generic collection.
Thoughts?
On Mon, Jun 13, 2011 at 10:31 AM, Blake Sullivan
mailto:blake.sulli...@oracle.com>> wrote:
On 6/13/11 9:22 AM, Andrew Robinson wrote:
https://issues.apache.org/jira/browse/TRINIDAD-2108
I am proposing to add a new Agent capability for touch devices.
It would involve adding:
static public final CapabilityKey CAP_TOUCH_SCREEN =
CapabilityKey.getCapabilityKey("touchScreen", true);
To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And
also adding the code to add this for the Andoid and iOS devices.
Any comments? Name of the key sound reasonable to everyone?
Thanks,
Andrew
I think that we want to consider the cases where the device
supports both touch gestures and other input devices at the same
time. So, it depends on the expected usage. Are consumers of
this api supposed to use it to query whether the device could send
them touch events, or are they expected to use it to determine
whether the device is primarily touch? If it is for the first
case, then I think we should expand the values to encompass the
quality of the touch events. For example, is multi-touch
supported? Anyway, we know from experience that we really don't
want to ever add any boolean values.
-- Blake Sullivan
Re: [TRINIDAD] Supporting touch capability
On 6/13/11 9:22 AM, Andrew Robinson wrote:
https://issues.apache.org/jira/browse/TRINIDAD-2108
I am proposing to add a new Agent capability for touch devices.
It would involve adding:
static public final CapabilityKey CAP_TOUCH_SCREEN =
CapabilityKey.getCapabilityKey("touchScreen", true);
To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And also
adding the code to add this for the Andoid and iOS devices.
Any comments? Name of the key sound reasonable to everyone?
Thanks,
Andrew
I think that we want to consider the cases where the device supports
both touch gestures and other input devices at the same time. So, it
depends on the expected usage. Are consumers of this api supposed to
use it to query whether the device could send them touch events, or are
they expected to use it to determine whether the device is primarily
touch? If it is for the first case, then I think we should expand the
values to encompass the quality of the touch events. For example, is
multi-touch supported? Anyway, we know from experience that we really
don't want to ever add any boolean values.
-- Blake Sullivan
Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)
I suspect that there are many cases where parent components are looking
at rendered on their children before deciding to traverse into these
children. If EL-binding rendered to the component is supported, then
the parent is either going to need to stop performing this optimization,
or it is going to have to ensure that the context is setup and torn down
around each call to isRendered.
-- Blake Sullivan
On 5/25/11 11:27 AM, Martin Koci wrote:
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
https://issues.apache.org/jira/browse/MYFACES-3157
Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has this
public void processRestoreState(FacesContext context, Object state)
{
if (context == null)
{
throw new NullPointerException("context");
}
Object[] stateValues = (Object[]) state;
try
{
// Call
UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
pushComponentToEL(context, this);
// Call the restoreState() method of this component.
restoreState(context, stateValues[0]);
The spec javadoc says the opposite, restoreState should be called "before"
pushComponentToEL but in practice that breaks UIComponent.EventListenerWrapper.
I reported the bug long time ago, but it wasn't fixed (I don't know why).
This case is similar. This should be fixed on the spec, but I don't
see a reason why we shouldn't commit that into myfaces code, because
after all, nobody relies on the buggy behavior.
I think we should open a new issue on the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
but fix it on myfaces code.
regards,
Leonardo Uribe
2011/5/25 Martin Koci:
Hi,
please notice the expression:
rendered="#{component.id eq 'testId'}"
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
-> #{component} resolves in rendered="#{}" to parent!
Problem 2.
MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:
(!isRendered())
return;
pushComponentToEL(context, this)
and from UIComponentBase.encodeBegin*
pushComponentToEL(context, this);
if (isRendered())
causes that example above renderes inputText, but never updates model.
Problem 3.
RendererUtils.renderChild(FacesContext, UIComponent):
in this method it is unappropriate to use following code:
if (!child.isRendered()) {
return;
}
child.encodeBegin(facesContext);
because:
1) it does not take into account pushComponentToEL ( #{component}
resolves to parent)
2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
"random" rendering - depends if parent of component renders it's
children or not! For this case I've created MYFACES-3126, but I'll
reopen it now, because simple remove of 'if (!child.isRendered())' does
not solve that problem and causes another problem if component
getRendersChildren = false;
What do yout think about this problem?
Regards,
Kočičák
Re: [core] performance: use indices instead of iterator (MYFACES-3130)
Mike, What Martin is talking about is that if the List doesn't implement the Marker interface RandomAccess then the List may implement indexed-based access through iteration, in which case iterating the list is n^2/2 -- Blake Sullivan On 5/10/11 1:17 PM, Mike Kienenberger wrote: If getChildren() is always of type List, then it really doesn't matter if it's ArrayList or ChildArrayList or some other kind of list. You can use indexes for any type of List. On Tue, May 10, 2011 at 4:11 PM, Martin Koci wrote: Hi, in current codebase, myfaces use mostly enhanced loop for iterating over chidren: for (UIComponent child: getChildren()) that creates new instance of iterator. After change to plain old indices: for (i = 0; i< childCount; i++) child = getChildren().get(i); I achieved following results in my test case: 1) number of AbstractList$Itr from ~ 100 000 down to ~1500 instances per one render/response 2) time for one render/response from ~1500ms down to ~900ms please see https://issues.apache.org/jira/browse/MYFACES-3130 for more details. We know that getChildren() is type of ArrayList (javax.faces.component._ComponentChildrenList) - in this situation is index-based loop safe change. But custom component can override implementation of getChildren() and provide own implementation which can be slower: I know about Trinidad: uses ArrayList too, so no risk here (org.apache.myfaces.trinidad.component.ChildArrayList) I use RichFaces and PrimeFaces too and don't see custom implementation of children in their codebase. What do you think about this problem? The performance gain is pretty big but also risky. Regards, Kočičák
Re: [Trinidad][API] web.xml context-param for skin cache size
I vote for 2. -- Blake Sullivan On 4/14/11 11:22 AM, Jeanne Waldman wrote: Here are some more options combined with the old top vote getters (1) MAX_CACHED_SKINS (2) MAX_SKINS_CACHED (3) MAX_SKINS_IN_CACHE (4) SKIN_MAX_CACHE_SIZE Still, my vote is Pavitra's take on Blake's, (2). It is the maximum number of skins that we cache, hence MAX_SKINS_CACHED Jeanne Pavitra Subramaniam wrote, On 4/13/2011 3:37 PM PT: On 4/13/2011 2:46 PM, Jeanne Waldman wrote: I like it too. It doesn't roll of the tongue, but I can't think of something simpler and better. You could try a slight variation "MAX_SKINS_CACHED". Prakash Udupa wrote, On 4/13/2011 2:36 PM PT: I think configurators are less likely to understand what a 'STYLE PROVIDER' means. So I like the simpler name Blake proposed 'org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS'. Thanks, Prakash On 4/13/2011 3:52 PM, Blake Sullivan wrote: On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 <https://issues.apache.org/jira/browse/TRINIDAD-2026>memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
Re: [Trinidad][API] web.xml context-param for skin cache size
On 4/13/11 1:13 PM, Jeanne Waldman wrote: Hi, For this issue, TRINIDAD-2026 <https://issues.apache.org/jira/browse/TRINIDAD-2026>memory leak in skinstyleprovider, I use a least-recently-used-map instead of a HashMap so I can limit the number of skins that I cache. This is useful if an application is built so that they have many skins, like if they have a skin per user, so that the numbe of cached skins doesn't keep growing and growing. I default to size 20, but this is also configurable via a web.xml context-parameter. Here are some proposed names: org.apache.myfaces.trinidad.skin.NUMBER_OF_SKINS_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_LRU_CACHE_SIZE in the patch it is org.apache.myfaces.trinidad.skin.SKIN_STYLE_PROVIDER_CACHE_SIZE, so if I don't hear any objections, this is what I will use. Thanks, Jeanne How about org.apache.myfaces.trinidad.skin.MAX_CACHED_SKINS? SKIN_STYLE_PROVIDER_CACHE_SIZE is more specific and more technically correct, though. -- Blake Sullivan
[jira] [Created] (TRINIDAD-2086) Trinidad uses relatively common parameters names that can conflict with component ids
Trinidad uses relatively common parameters names that can conflict with component ids - Key: TRINIDAD-2086 URL: https://issues.apache.org/jira/browse/TRINIDAD-2086 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 1.2.14-core , 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Blake Sullivan Trinidad uses relatively common names for some of the POST parameters that it uses for decoding the response, namely: "source", "event", and "targetItem". These names can conflict with the client ids of components on the page, leading to bizarre behavior. The solution would be to switch to using parameters that begin with a prefix or characters that are illegal for HTML names and ids in order to avoid the conflict. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2085) absolute urls for icon selectors preprends context-root when it shouldn't
[
https://issues.apache.org/jira/browse/TRINIDAD-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017241#comment-13017241
]
Blake Sullivan commented on TRINIDAD-2085:
--
Looks good. Calling URI.isAbsolute() is much better than my idea of checking
if the scheme is non-empty
> absolute urls for icon selectors preprends context-root when it shouldn't
> -
>
> Key: TRINIDAD-2085
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2085
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Skinning
>Reporter: Jeanne Waldman
> Attachments: isAbsoluteURIPatch.patch
>
>
> In the trinidad demo purple.css skin file, type an absolute url like
> this one:
> .AFErrorIcon:alias { content:
> url('http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png');
> }
> set trinidad-config.xml to use the purple skin
> run af:icon demo
> Type in 'error' for the type
> Use firebug and hover on the Error text. You will see that the url has the
> context-root prepended to it, when it shouldn't.
> ACTUAL
> class="AFErrorIconStyle"
> src="/trinidad-demo-context-root/http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png";>
> EXPECTED
> class="AFErrorIconStyle"
> src="http://127.0.0.1:7101/trinidadt-demo-context-root/faces/afr/skins/purple/images/info.png";>
> absolute urls work fine for background-images that are written to the css
> file. This is strictly a Skinning Framework Icon issue. Possibly we are
> creating the wrong type of Icon (ContextImageIcon instead of URIIIcon) when
> we create Icons in StyleSheetDocument or SkinStyleSheetParserUtils.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2085) absolute urls for icon selectors preprends context-root when it shouldn't
[
https://issues.apache.org/jira/browse/TRINIDAD-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017222#comment-13017222
]
Blake Sullivan commented on TRINIDAD-2085:
--
The fix checked into trunk checks to see whether the URL begins with "http",
which covers "http" and "https", however it would be more correct to actually
look to see if the protocol part of the URL exists. I think it would be more
correct to check the String for a ":" and if it contains one, create a URI from
the String and see if the scheme part is non-empty. This would also avoid
issues with the protocol being case insensitive, so users are allowed to use
"HTTP:" or "Http:"
> absolute urls for icon selectors preprends context-root when it shouldn't
> -
>
> Key: TRINIDAD-2085
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2085
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Skinning
>Reporter: Jeanne Waldman
>
> In the trinidad demo purple.css skin file, type an absolute url like
> this one:
> .AFErrorIcon:alias { content:
> url('http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png');
> }
> set trinidad-config.xml to use the purple skin
> run af:icon demo
> Type in 'error' for the type
> Use firebug and hover on the Error text. You will see that the url has the
> context-root prepended to it, when it shouldn't.
> ACTUAL
> class="AFErrorIconStyle"
> src="/trinidad-demo-context-root/http://127.0.0.1:7101/trinidad-demo-context-root/faces/afr/skins/purple/images/info.png";>
> EXPECTED
> class="AFErrorIconStyle"
> src="http://127.0.0.1:7101/trinidadt-demo-context-root/faces/afr/skins/purple/images/info.png";>
> absolute urls work fine for background-images that are written to the css
> file. This is strictly a Skinning Framework Icon issue. Possibly we are
> creating the wrong type of Icon (ContextImageIcon instead of URIIIcon) when
> we create Icons in StyleSheetDocument or SkinStyleSheetParserUtils.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[trinidad][api] TRINIDAD-2078 SKIP_ITERATION forces visit of non-rendered components
To fix TRINIDAD-2078 SKIP_ITERATION forces visit of non-rendered components <https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015621#comment-13015621>, I proposed the following apis: The proposed patch fixes the problem by reverting to delegating the visiting of the children back to the components. We then: 1) Add to ComponentUtils: /** * @param visitContext * @return true if this is a non-iterating visit. */ public static boolean isSkipIterationVisit(VisitContext visitContext) So that Components can determine whether they should iterate when tree visiting And modify the behavior of UIXCollection since it is the base class of all of the iterating components in Trinidad to switch inside it's override of visitChildren and call a new protected method: /** * Performs a non-iterating visit of the children. The default implementation visits all * of the children. If the UIXCollection subclass doesn't visit some of its children in * certain cases, it needs to override this method. * @param visitContext * @param callback * @return */ protected boolean visitChildrenWithoutIterating( instead of the normal data visiting code if we are in a skip iteration visit. For convenience, I also made the following method on UIXComponent public: /** * Default implementation of visiting children that visits all children without iterating * @param visitContext the VisitContext for this visit * @param callback the VisitCallback instance * @return true if the visit is complete. */ protected final boolean visitAllChildren( VisitContext visitContext, VisitCallback callback) And made it the default implementation of visitChildrenWithoutIterating(), which should be sufficient for all of the subclasses of UIXCollection that ship with Trinidad. It also happens to be precisely the same behavior as the old code we are fixing. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[
https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015644#comment-13015644
]
Blake Sullivan commented on TRINIDAD-1496:
--
I guess a getRawURI function is fine. Its javadoc should probably point back
to http://myfaces.apache.org/trinidad/devguide/skinning.html#urls
I think that at the same time, we want to make the following documentation
changes to clarify what is going on:
1) In http://myfaces.apache.org/trinidad/devguide/skinning.html#urls
Add to the relative URL documentation that the URL will be relative to the
document that the content is generated into--the rendered document for icons
and the generated CSS file for everything else.
2) Change the getImageURI documentation to state that the returned URI is
suitable for rendering directly into rendered content, for example HTML. The
current documentation is extremely vague about what kind of URI is returned and
we want to make clear the difference between this URI and the getRawURI
> Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value
> instead of just getImageURI
> --
>
> Key: TRINIDAD-1496
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1496
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Components
>Affects Versions: 1.2.11-core
>Reporter: Matt Cooper
>Priority: Minor
>
> In skinning, you can define image icons in 4 different ways:
> 1.) Absolute URLs specify the complete URL to the resource, including the
> protocol (e.g. http://). Example:
> content: url(http://incubator.apache.org/images/asf_logo_wide.gif);
> 2.) Relative URLs are used if the specified URL does not start with a slash
> ("/") and if there's no protocol present. A relative URL is based on the
> skin's CSS file location. For instance, if the CSS is located in
> MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then
> the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example:
> content: url(skin_images/ObjectIconError.gif);
> 3.) Context relative URLs are resolved relatively to the context root of the
> web application. To use them, you simply have to make it start with a single
> slash ("/"). For instance, if the context root is /MyWebApp and the specified
> URL is /images/myImage.jpeg, the resulting URL will be
> /MyWebApp/images/myImage.jpeg. Example:
> content: url(/skins/mySkin/skin_images/ObjectIconError.gif);
> 4.) Server relative URLs are resolved relatively to the web server as opposed
> to the context root. This allow to easily refer to resources located on
> another application on the same server. To use this type of URL, the
> specified URL must starts with two slashes ("//"). Example:
> content: url(//MyOtherWebApp/images/myCalendar.gif);
> The org.apache.myfaces.trinidad.skin.Icon class currently provides a
> getImageURI() method. This method returns a value that has the context path
> built-in. If a component exposes an icon attribute (there are a handful in
> Apache MyFaces Trinidad and also in another framework that has components
> built upon Trinidad), that icon String supports these same alternative
> mechanisms for referring to the icon image. Let's say you have a component
> that you want to keep abstract but might want it to reuse existing components
> (e.g. a rich text editor with a toolbar containing buttons that you want to
> reuse an existing toolbar button component so you can have consistency in
> button styling). For that publicly-exposed component, you will want to allow
> people to customize in skinning what the icons are for its toolbar. These
> icons must be defined in that publicly-exposed component but then converted
> into a String that can be passed into the toolbar button component. With the
> current Icon.getImageURI(), if a user skinned the icon image using some of
> the 4 above paths, either the icon would have 2 context paths added to it
> (one from the skin framework and one from the toolbar button resource
> encoding) or it would have a context path when it should not be including the
> local context path (image definition option #4). For the public component's
> renderer to support all 4 of these image definition options, the
> org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to
> either let it have access to the raw content value so that raw value can be
> passed along to the button or at least some kind of mechanism to let the
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[
https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015647#comment-13015647
]
Blake Sullivan commented on TRINIDAD-1496:
--
I forgot to say that I agree that the relative URL case for icons isn't
especially useful--it would only really work if all of the pages were in the
same directory
> Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value
> instead of just getImageURI
> --
>
> Key: TRINIDAD-1496
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1496
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Components
>Affects Versions: 1.2.11-core
>Reporter: Matt Cooper
>Priority: Minor
>
> In skinning, you can define image icons in 4 different ways:
> 1.) Absolute URLs specify the complete URL to the resource, including the
> protocol (e.g. http://). Example:
> content: url(http://incubator.apache.org/images/asf_logo_wide.gif);
> 2.) Relative URLs are used if the specified URL does not start with a slash
> ("/") and if there's no protocol present. A relative URL is based on the
> skin's CSS file location. For instance, if the CSS is located in
> MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then
> the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example:
> content: url(skin_images/ObjectIconError.gif);
> 3.) Context relative URLs are resolved relatively to the context root of the
> web application. To use them, you simply have to make it start with a single
> slash ("/"). For instance, if the context root is /MyWebApp and the specified
> URL is /images/myImage.jpeg, the resulting URL will be
> /MyWebApp/images/myImage.jpeg. Example:
> content: url(/skins/mySkin/skin_images/ObjectIconError.gif);
> 4.) Server relative URLs are resolved relatively to the web server as opposed
> to the context root. This allow to easily refer to resources located on
> another application on the same server. To use this type of URL, the
> specified URL must starts with two slashes ("//"). Example:
> content: url(//MyOtherWebApp/images/myCalendar.gif);
> The org.apache.myfaces.trinidad.skin.Icon class currently provides a
> getImageURI() method. This method returns a value that has the context path
> built-in. If a component exposes an icon attribute (there are a handful in
> Apache MyFaces Trinidad and also in another framework that has components
> built upon Trinidad), that icon String supports these same alternative
> mechanisms for referring to the icon image. Let's say you have a component
> that you want to keep abstract but might want it to reuse existing components
> (e.g. a rich text editor with a toolbar containing buttons that you want to
> reuse an existing toolbar button component so you can have consistency in
> button styling). For that publicly-exposed component, you will want to allow
> people to customize in skinning what the icons are for its toolbar. These
> icons must be defined in that publicly-exposed component but then converted
> into a String that can be passed into the toolbar button component. With the
> current Icon.getImageURI(), if a user skinned the icon image using some of
> the 4 above paths, either the icon would have 2 context paths added to it
> (one from the skin framework and one from the toolbar button resource
> encoding) or it would have a context path when it should not be including the
> local context path (image definition option #4). For the public component's
> renderer to support all 4 of these image definition options, the
> org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to
> either let it have access to the raw content value so that raw value can be
> passed along to the button or at least some kind of mechanism to let the
> public component's renderer know that it is not safe to let the button add
> its own copy of the context path (e.g. add another leading "/" to the result).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components
[ https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015621#comment-13015621 ] Blake Sullivan commented on TRINIDAD-2078: -- The proposed patch fixes the problem by reverting to delegating the visiting of the children back to the components. We then: 1) Add to ComponentUtils: /** * @param visitContext * @return true if this is a non-iterating visit. */ public static boolean isSkipIterationVisit(VisitContext visitContext) So that Components can determine whether they should iterate when tree visiting And modify the behavior of UIXCollection since it is the base class of all of the iterating components in Trinidad to switch inside it's override of visitChildren and call a new protected method: /** * Performs a non-iterating visit of the children. The default implementation visits all * of the children. If the UIXCollection subclass doesn't visit some of its children in * certain cases, it needs to override this method. * @param visitContext * @param callback * @return */ protected boolean visitChildrenWithoutIterating( instead of the normal data visiting code if we are in a skip iteration visit. For convenience, I also made the following method on UIXComponent public: /** * Default implementation of visiting children that visits all children without iterating * @param visitContext the VisitContext for this visit * @param callback the VisitCallback instance * @return true if the visit is complete. */ protected final boolean visitAllChildren( VisitContext visitContext, VisitCallback callback) And made it the default implementation of visitChildrenWithoutIterating(), which should be sufficient for all of the subclasses of UIXCollection that ship with Trinidad. It also happens to be precisely the same behavior as the old code we are fixing. > SKIP_ITERATION forces visit of non-rendered components > -- > > Key: TRINIDAD-2078 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2078 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.0.0-beta-2 >Reporter: Andy Schwartz >Assignee: Blake Sullivan > Attachments: trin2078_trin2.diff > > > Certain tree visits, such as the PostRestoreStateEvent delivery visit, must > avoid iteration in stamping components (eg. UIData). Before the fix for: > TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property > This was handled in UIXComponent.visitChildren() by checking for the restore > view phase. > As of the fix for 2030, instead of checking the phase id we now check for the > SKIP_ITERATION pseudo-hint. > While this works correctly for the PostRestoreStateEvent visit, it fails in > other cases. The problem: UIXComponent.visitChildren() falls back on a > "facets and children" traversal when SKIP_ITERATION is set, which means that > we will visit all children (both rendered and non-rendered) even when the > SKIP_UNRENDERED hint is set. > Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly > supported with our current solution. Since this is a valid combination of > hints, we'll need an approach that correctly supports this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components
[ https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2078: - Status: Open (was: Patch Available) > SKIP_ITERATION forces visit of non-rendered components > -- > > Key: TRINIDAD-2078 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2078 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.0.0-beta-2 >Reporter: Andy Schwartz > Assignee: Blake Sullivan > Attachments: trin2078_trin2.diff > > > Certain tree visits, such as the PostRestoreStateEvent delivery visit, must > avoid iteration in stamping components (eg. UIData). Before the fix for: > TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property > This was handled in UIXComponent.visitChildren() by checking for the restore > view phase. > As of the fix for 2030, instead of checking the phase id we now check for the > SKIP_ITERATION pseudo-hint. > While this works correctly for the PostRestoreStateEvent visit, it fails in > other cases. The problem: UIXComponent.visitChildren() falls back on a > "facets and children" traversal when SKIP_ITERATION is set, which means that > we will visit all children (both rendered and non-rendered) even when the > SKIP_UNRENDERED hint is set. > Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly > supported with our current solution. Since this is a valid combination of > hints, we'll need an approach that correctly supports this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2078) SKIP_ITERATION forces visit of non-rendered components
[ https://issues.apache.org/jira/browse/TRINIDAD-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2078: - Status: Patch Available (was: Open) > SKIP_ITERATION forces visit of non-rendered components > -- > > Key: TRINIDAD-2078 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2078 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.0.0-beta-2 >Reporter: Andy Schwartz > Assignee: Blake Sullivan > Attachments: trin2078_trin2.diff > > > Certain tree visits, such as the PostRestoreStateEvent delivery visit, must > avoid iteration in stamping components (eg. UIData). Before the fix for: > TRINIDAD-2030 Honor SKIP_ITERATION FacesContext property > This was handled in UIXComponent.visitChildren() by checking for the restore > view phase. > As of the fix for 2030, instead of checking the phase id we now check for the > SKIP_ITERATION pseudo-hint. > While this works correctly for the PostRestoreStateEvent visit, it fails in > other cases. The problem: UIXComponent.visitChildren() falls back on a > "facets and children" traversal when SKIP_ITERATION is set, which means that > we will visit all children (both rendered and non-rendered) even when the > SKIP_UNRENDERED hint is set. > Thus, the combination of SKIP_ITERATION and SKIP_UNRENDERED is not correctly > supported with our current solution. Since this is a valid combination of > hints, we'll need an approach that correctly supports this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2074) RowKeySetAttributeChange doesn't check if oldValue is non-null and a RowKeySet before casting and dereferencing
RowKeySetAttributeChange doesn't check if oldValue is non-null and a RowKeySet
before casting and dereferencing
---
Key: TRINIDAD-2074
URL: https://issues.apache.org/jira/browse/TRINIDAD-2074
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.12-core, 2.0.0-beta-3
Reporter: Blake Sullivan
The problem is in the GetOldValueAndUpdate.invokeContextCallback()
implementation.
We want to reuse the oldValue if one exists, but don't check that the
oldValue is non-null. The UIXTable and UIXTree aren't supposed to return
null values, but unfortunately do in some strange cases. Regardless, the
safe thing to do is to check for null, and in fact, the safer thing to do is
to ensure that the oldValue is an instanceOf RowKeySet (which also catches
the null case), since we are going to cast to a RowKeySet.
This turns into a one line addition of an if check:
if (oldValue instanceof RowKeySet)
{
RowKeySetAttributeChange._updateKeySet(null,
(RowKeySet)oldValue,
_newKeySet);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1 -- Blake Sullivan On 3/24/11 9:32 AM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being "metadata complete" in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
[jira] [Updated] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2067: - Status: Patch Available (was: Open) > setUpEncodingContext called twice on all partial page rendered roots during > optimized PPR > - > > Key: TRINIDAD-2067 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Archetype >Affects Versions: 2.0.0-beta-3 > Reporter: Blake Sullivan >Assignee: Blake Sullivan > Fix For: 2.0.0-beta-3 > > Attachments: trin2067_2B3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > setUpEncodingContext is called on all of the partial page roots during > optimized partial page rendering. This is because optimizedPPR uses a tree > visit to visit the partial page roots to render and the tree visiting code > calls setUpEncodingContext before calling the visit callback. The optimized > PPR code then calls encodeAll() on the partial target, which calls > beforeEncode(), which calls setupEncodingContext again. This breaks code > that can't have its setupEncodingContext (and tearDownEncodingContext) called > twice in a row. A good example is a form renderer that uses > setupEncodingContext to catch cases where forms have been nested. > The fix is to add an api to UIXComponent: > /** >* Calls the VisitCallback after popping the encoding or visiting context > of the >* current component and then restores that context, returning the > VisitCallbacks's >* response. This handles the rare cases where a VisitCallback should not > be >* called inside the target component's callback. >* @param visitContext the VisitContext for this visit >* @param component the UIComponent to pop the context of >* @param callback the VisitCallback instance to call in the > popped context >* @return the result of the VisitCallback >*/ > public static VisitResult visitOutsideOfContext( > VisitContext visitContext, > UIComponent component, > VisitCallback callback) > The optimized PPR code can then wrap its current VisitCallback in one that > calls visitOutsideOfContext, passing in the original VisitCallback. > Other solutions would attempt to change the optimized PPR code to attempt to > avoid calling encodeAll when the target was a UIXComponent, however doing so > would require making assumptions about how different components have > implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2067: - Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Status: Resolved (was: Patch Available) Fixed by making visitTree not call setupEncodingContext before invoking the VisitCallback during a ppr visit. > setUpEncodingContext called twice on all partial page rendered roots during > optimized PPR > - > > Key: TRINIDAD-2067 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Archetype >Affects Versions: 2.0.0-beta-3 > Reporter: Blake Sullivan >Assignee: Blake Sullivan > Fix For: 2.0.0-beta-3 > > Attachments: trin2067_2B3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > setUpEncodingContext is called on all of the partial page roots during > optimized partial page rendering. This is because optimizedPPR uses a tree > visit to visit the partial page roots to render and the tree visiting code > calls setUpEncodingContext before calling the visit callback. The optimized > PPR code then calls encodeAll() on the partial target, which calls > beforeEncode(), which calls setupEncodingContext again. This breaks code > that can't have its setupEncodingContext (and tearDownEncodingContext) called > twice in a row. A good example is a form renderer that uses > setupEncodingContext to catch cases where forms have been nested. > The fix is to add an api to UIXComponent: > /** >* Calls the VisitCallback after popping the encoding or visiting context > of the >* current component and then restores that context, returning the > VisitCallbacks's >* response. This handles the rare cases where a VisitCallback should not > be >* called inside the target component's callback. >* @param visitContext the VisitContext for this visit >* @param component the UIComponent to pop the context of >* @param callback the VisitCallback instance to call in the > popped context >* @return the result of the VisitCallback >*/ > public static VisitResult visitOutsideOfContext( > VisitContext visitContext, > UIComponent component, > VisitCallback callback) > The optimized PPR code can then wrap its current VisitCallback in one that > calls visitOutsideOfContext, passing in the original VisitCallback. > Other solutions would attempt to change the optimized PPR code to attempt to > avoid calling encodeAll when the target was a UIXComponent, however doing so > would require making assumptions about how different components have > implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009293#comment-13009293 ] Blake Sullivan commented on TRINIDAD-2067: -- resolved in 2.0.beta3 in revision 1083899 > setUpEncodingContext called twice on all partial page rendered roots during > optimized PPR > - > > Key: TRINIDAD-2067 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Archetype >Affects Versions: 2.0.0-beta-3 >Reporter: Blake Sullivan >Assignee: Blake Sullivan > Fix For: 2.0.0-beta-3 > > Attachments: trin2067_2B3.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > setUpEncodingContext is called on all of the partial page roots during > optimized partial page rendering. This is because optimizedPPR uses a tree > visit to visit the partial page roots to render and the tree visiting code > calls setUpEncodingContext before calling the visit callback. The optimized > PPR code then calls encodeAll() on the partial target, which calls > beforeEncode(), which calls setupEncodingContext again. This breaks code > that can't have its setupEncodingContext (and tearDownEncodingContext) called > twice in a row. A good example is a form renderer that uses > setupEncodingContext to catch cases where forms have been nested. > The fix is to add an api to UIXComponent: > /** >* Calls the VisitCallback after popping the encoding or visiting context > of the >* current component and then restores that context, returning the > VisitCallbacks's >* response. This handles the rare cases where a VisitCallback should not > be >* called inside the target component's callback. >* @param visitContext the VisitContext for this visit >* @param component the UIComponent to pop the context of >* @param callback the VisitCallback instance to call in the > popped context >* @return the result of the VisitCallback >*/ > public static VisitResult visitOutsideOfContext( > VisitContext visitContext, > UIComponent component, > VisitCallback callback) > The optimized PPR code can then wrap its current VisitCallback in one that > calls visitOutsideOfContext, passing in the original VisitCallback. > Other solutions would attempt to change the optimized PPR code to attempt to > avoid calling encodeAll when the target was a UIXComponent, however doing so > would require making assumptions about how different components have > implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
[ https://issues.apache.org/jira/browse/TRINIDAD-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009284#comment-13009284 ] Blake Sullivan commented on TRINIDAD-2067: -- Rather than adding an api, I went with a behavior change--during a partial encoding visit, we no longer call setupEncodingContext before invoking the visitCallback. If the VisitResult is ACCEPT, we do continue to call setupEncodingContext before setupChildrenEncodingContext > setUpEncodingContext called twice on all partial page rendered roots during > optimized PPR > - > > Key: TRINIDAD-2067 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Archetype >Affects Versions: 2.0.0-beta-3 >Reporter: Blake Sullivan >Assignee: Blake Sullivan > Original Estimate: 24h > Remaining Estimate: 24h > > setUpEncodingContext is called on all of the partial page roots during > optimized partial page rendering. This is because optimizedPPR uses a tree > visit to visit the partial page roots to render and the tree visiting code > calls setUpEncodingContext before calling the visit callback. The optimized > PPR code then calls encodeAll() on the partial target, which calls > beforeEncode(), which calls setupEncodingContext again. This breaks code > that can't have its setupEncodingContext (and tearDownEncodingContext) called > twice in a row. A good example is a form renderer that uses > setupEncodingContext to catch cases where forms have been nested. > The fix is to add an api to UIXComponent: > /** >* Calls the VisitCallback after popping the encoding or visiting context > of the >* current component and then restores that context, returning the > VisitCallbacks's >* response. This handles the rare cases where a VisitCallback should not > be >* called inside the target component's callback. >* @param visitContext the VisitContext for this visit >* @param component the UIComponent to pop the context of >* @param callback the VisitCallback instance to call in the > popped context >* @return the result of the VisitCallback >*/ > public static VisitResult visitOutsideOfContext( > VisitContext visitContext, > UIComponent component, > VisitCallback callback) > The optimized PPR code can then wrap its current VisitCallback in one that > calls visitOutsideOfContext, passing in the original VisitCallback. > Other solutions would attempt to change the optimized PPR code to attempt to > avoid calling encodeAll when the target was a UIXComponent, however doing so > would require making assumptions about how different components have > implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[trinidad][api] (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
The below api is a little gross, but I don't see a better solution to the problem. -- Blake Sullivan Original Message Subject: [jira] Created: (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR Date: Fri, 18 Mar 2011 01:32:29 + (UTC) From: Blake Sullivan (JIRA) Reply-To: MyFaces Development To: dev@myfaces.apache.org setUpEncodingContext called twice on all partial page rendered roots during optimized PPR - Key: TRINIDAD-2067 URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Blake Sullivan setUpEncodingContext is called on all of the partial page roots during optimized partial page rendering. This is because optimizedPPR uses a tree visit to visit the partial page roots to render and the tree visiting code calls setUpEncodingContext before calling the visit callback. The optimized PPR code then calls encodeAll() on the partial target, which calls beforeEncode(), which calls setupEncodingContext again. This breaks code that can't have its setupEncodingContext (and tearDownEncodingContext) called twice in a row. A good example is a form renderer that uses setupEncodingContext to catch cases where forms have been nested. The fix is to add an api to UIXComponent: /** * Calls the VisitCallback after popping the encoding or visiting context of the * current component and then restores that context, returning the VisitCallbacks's * response. This handles the rare cases where a VisitCallback should not be * called inside the target component's callback. * @param visitContext theVisitContext for this visit * @param component theUIComponent to pop the context of * @param callback theVisitCallback instance to call in the popped context * @return the result of the VisitCallback */ public static VisitResult visitOutsideOfContext( VisitContext visitContext, UIComponent component, VisitCallback callback) The optimized PPR code can then wrap its current VisitCallback in one that calls visitOutsideOfContext, passing in the original VisitCallback. Other solutions would attempt to change the optimized PPR code to attempt to avoid calling encodeAll when the target was a UIXComponent, however doing so would require making assumptions about how different components have implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2067) setUpEncodingContext called twice on all partial page rendered roots during optimized PPR
setUpEncodingContext called twice on all partial page rendered roots during optimized PPR - Key: TRINIDAD-2067 URL: https://issues.apache.org/jira/browse/TRINIDAD-2067 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Blake Sullivan setUpEncodingContext is called on all of the partial page roots during optimized partial page rendering. This is because optimizedPPR uses a tree visit to visit the partial page roots to render and the tree visiting code calls setUpEncodingContext before calling the visit callback. The optimized PPR code then calls encodeAll() on the partial target, which calls beforeEncode(), which calls setupEncodingContext again. This breaks code that can't have its setupEncodingContext (and tearDownEncodingContext) called twice in a row. A good example is a form renderer that uses setupEncodingContext to catch cases where forms have been nested. The fix is to add an api to UIXComponent: /** * Calls the VisitCallback after popping the encoding or visiting context of the * current component and then restores that context, returning the VisitCallbacks's * response. This handles the rare cases where a VisitCallback should not be * called inside the target component's callback. * @param visitContext the VisitContext for this visit * @param component the UIComponent to pop the context of * @param callback the VisitCallback instance to call in the popped context * @return the result of the VisitCallback */ public static VisitResult visitOutsideOfContext( VisitContext visitContext, UIComponent component, VisitCallback callback) The optimized PPR code can then wrap its current VisitCallback in one that calls visitOutsideOfContext, passing in the original VisitCallback. Other solutions would attempt to change the optimized PPR code to attempt to avoid calling encodeAll when the target was a UIXComponent, however doing so would require making assumptions about how different components have implemented encodeAll(), violating its abstraction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: PMC chair of Apache MyFaces changed
Matthias, Thanks for all of your hard work. Gerhard, congratulations and I look forward to working with you. -- Blake On 3/17/11 12:20 AM, Matthias Wessendorf wrote: Hi, I am stepping back from being the Apache MyFaces PMC chair. The MyFaces PMC did vote (internally) that Gerhard Petracek would be a very good PMC chair. Yesterday, during the board meeting, this has been made official. Please join me in welcoming Gerhard as being the new PMC chair of Apache MyFaces! Congrats, Gerhard! -Matthias
[jira] Commented: (TRINIDAD-2057) UIXTree/UIXTreeTable/UIXTable RowKeySets require that their attributes are only fetched when the component is in context
[ https://issues.apache.org/jira/browse/TRINIDAD-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005452#comment-13005452 ] Blake Sullivan commented on TRINIDAD-2057: -- Fixed in 1.2.12.5 in revision 1080420 > UIXTree/UIXTreeTable/UIXTable RowKeySets require that their attributes are > only fetched when the component is in context > > > Key: TRINIDAD-2057 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2057 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.2.15-core , 2.0.0-beta-3 >Reporter: Blake Sullivan >Assignee: Blake Sullivan > Attachments: RowKey-1.2.12.5.0-branch.patch, trin_2057_1_2_x.diff, > trin_2057_2_x.diff > > > Due to the way the RowKeySets for these components are implemented, they need > to set the CollectionModel that the component is attached to when the > RowKeySet is created. Since the CollectionModel may be EL-bound, this means > that the attributes can only be fetched when the component is in context. > This is different than how things are supposed to work in JSF, where an > attribute should only need to be fetched in context if the attribute is > EL-bound > In the short term, the fix is to hack on the RowKeySetAttributeChange, but > the longer term fix is to fix these components. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2060) Make Optimized PPR the default with a public flag to disable it at the web.xml and application levels
[ https://issues.apache.org/jira/browse/TRINIDAD-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2060: - Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Status: Resolved (was: Patch Available) Fixed in revision 1080418 > Make Optimized PPR the default with a public flag to disable it at the > web.xml and application levels > - > > Key: TRINIDAD-2060 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2060 > Project: MyFaces Trinidad > Issue Type: Improvement >Affects Versions: 2.0.0-beta-3 > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Fix For: 2.0.0-beta-3 > > Attachments: trin2060_2b3.diff > > Original Estimate: 4h > Remaining Estimate: 4h > > Optimized PPR is currently enabled using the internal web.xml > flag:"org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION" to enable > PPR Optimization in web.xml and the following internal application map > property "org.apache.myfaces.trinidadinternal.DISABLE_PPR_OPTIMIZATION" to > dynamically turn PPR optimization on and off. > PPR Optimization currently defaults off > The proposal is to: > 1) Make PPR Optimization default to "on" now that we've tested the components > and fixed the tree visiting bugs > 2) Support a public flag in case an application is working with a third party > component that doesn't support PPR optmization > 3) Make the application and web.xml flags the same to avoid confusion (the > application flag is useful for debugging) > 4) Use the value "on" and "off" in case we need to add a third value later -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2060) Make Optimized PPR the default with a public flag to disable it at the web.xml and application levels
[ https://issues.apache.org/jira/browse/TRINIDAD-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Sullivan updated TRINIDAD-2060: - Status: Patch Available (was: Open) > Make Optimized PPR the default with a public flag to disable it at the > web.xml and application levels > - > > Key: TRINIDAD-2060 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2060 > Project: MyFaces Trinidad > Issue Type: Improvement >Affects Versions: 2.0.0-beta-3 > Reporter: Blake Sullivan > Assignee: Blake Sullivan >Priority: Minor > Original Estimate: 4h > Remaining Estimate: 4h > > Optimized PPR is currently enabled using the internal web.xml > flag:"org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION" to enable > PPR Optimization in web.xml and the following internal application map > property "org.apache.myfaces.trinidadinternal.DISABLE_PPR_OPTIMIZATION" to > dynamically turn PPR optimization on and off. > PPR Optimization currently defaults off > The proposal is to: > 1) Make PPR Optimization default to "on" now that we've tested the components > and fixed the tree visiting bugs > 2) Support a public flag in case an application is working with a third party > component that doesn't support PPR optmization > 3) Make the application and web.xml flags the same to avoid confusion (the > application flag is useful for debugging) > 4) Use the value "on" and "off" in case we need to add a third value later -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2060) Make Optimized PPR the default with a public flag to disable it at the web.xml and application levels
[ https://issues.apache.org/jira/browse/TRINIDAD-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005435#comment-13005435 ] Blake Sullivan commented on TRINIDAD-2060: -- The name of the property will be "org.apache.myfaces.trinidad.PPR_OPTIMIZATION" > Make Optimized PPR the default with a public flag to disable it at the > web.xml and application levels > - > > Key: TRINIDAD-2060 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2060 > Project: MyFaces Trinidad > Issue Type: Improvement >Affects Versions: 2.0.0-beta-3 >Reporter: Blake Sullivan >Assignee: Blake Sullivan >Priority: Minor > Original Estimate: 4h > Remaining Estimate: 4h > > Optimized PPR is currently enabled using the internal web.xml > flag:"org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION" to enable > PPR Optimization in web.xml and the following internal application map > property "org.apache.myfaces.trinidadinternal.DISABLE_PPR_OPTIMIZATION" to > dynamically turn PPR optimization on and off. > PPR Optimization currently defaults off > The proposal is to: > 1) Make PPR Optimization default to "on" now that we've tested the components > and fixed the tree visiting bugs > 2) Support a public flag in case an application is working with a third party > component that doesn't support PPR optmization > 3) Make the application and web.xml flags the same to avoid confusion (the > application flag is useful for debugging) > 4) Use the value "on" and "off" in case we need to add a third value later -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2060) Make Optimized PPR the default with a public flag to disable it at the web.xml and application levels
Make Optimized PPR the default with a public flag to disable it at the web.xml and application levels - Key: TRINIDAD-2060 URL: https://issues.apache.org/jira/browse/TRINIDAD-2060 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-beta-3 Reporter: Blake Sullivan Assignee: Blake Sullivan Priority: Minor Optimized PPR is currently enabled using the internal web.xml flag:"org.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION" to enable PPR Optimization in web.xml and the following internal application map property "org.apache.myfaces.trinidadinternal.DISABLE_PPR_OPTIMIZATION" to dynamically turn PPR optimization on and off. PPR Optimization currently defaults off The proposal is to: 1) Make PPR Optimization default to "on" now that we've tested the components and fixed the tree visiting bugs 2) Support a public flag in case an application is working with a third party component that doesn't support PPR optmization 3) Make the application and web.xml flags the same to avoid confusion (the application flag is useful for debugging) 4) Use the value "on" and "off" in case we need to add a third value later -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad] ChangeManagerWrapper API
The names can't be the same because if we implemented the Wrapper interface, the new method would have to be public, however if someone had subclassed the protected method, keeping it protected, that change would break their code because you can't subclass a method and reduce its visibility. -- Blake Sullivan On 3/10/11 12:20 PM, Scott O'Bryan wrote: I suppose I don't mind the currently implementation but I'm not sure I understand Point #2. Adding an interface does not change binary backward compatibility does it? Likewise, having a public getWrapped() method wouldn't have any conflicts if the interface was applied later. From a "pretty code" POV, I like the idea of wrappers being implemented in a consistent fashion. Takes away a lot of confusion. In the end though, Trinidad has a lot of wrappers which are already implemented in different ways. What's one more going to hurt.. :D Scott On 03/10/2011 11:37 AM, Andy Schwartz wrote: Thanks for the review Pavitra. I too was debating whether to follow the FacesWrapper approach. In the end I leaned towards keeping the get*Wrapper method protected, since I couldn't think of any non-hacky reason for exposing this publicly. On Wed, Mar 9, 2011 at 6:13 PM, Blake Sullivan wrote: 1) Is because there is currently no good reason for developers to burrow into the ChangeManager implementations Right. 2) Is because if we did come up with a good reason to implement FacesWrapper, we need to be able to do so in a backwards compatible manner Exactly. My initial implementation contained a protected getWrapped() method, though I ended up picking a different name for this protected hook since I wanted to leave open the possibility of implementing FacesWrapper (and exposing a public getWrapped() method) in the future should the need arise. Andy
Re: [Trinidad] New utility method: ComponentUtils.getNonFlatteningAncestor()
Looks good. -- Blake Sullivan On 3/10/11 11:36 AM, Andy Schwartz wrote: Gang - I would like to add a utility method for locating the nearest non-flattening ancestor component, as discussed here: https://issues.apache.org/jira/browse/TRINIDAD-2056 And shown in this patch: https://issues.apache.org/jira/secure/attachment/12473314/trinidad-2056.patch Any comments? Andy
