FacesMessage spec violations
Just to ping dev@ and remind them to view: * MYFACES-3140 - FacesMessage.VALUES is not ordered properly * MYFACES-3141 - FacesMessage implements Serializable but cannot be serialized Thanks! Matt
Re: [core] do not check for duplicate ids when saving view on production stage
On Fri, May 20, 2011 at 2:40 AM, Jakob Korherr wrote: > Sounds great. But with regard to your third point, what about keeping > it more general? Maybe we later want to extend it to something we > don't want to check in production that has nothing to do with IDs > whatsoever? > > Maybe > > org.apache.myfaces.DISABLE_PRODUCTION_CHECKS or > org.apache.myfaces.DISABLE_PRODUCTION_INSPECTIONS or > org.apache.myfaces.DISABLE_INSPECTIONS_IN_PRODUCTION > org.apache.myfaces.OPTIMIZE_PRODUCTION? Or... org.apache.myfaces.OPTIMIZE_PROJECT_STAGES = e.g. SystemTest,Production Matt > (default=false) would fit. However, I am usually not very good with > names, so maybe we will find something better! > > Regards, > Jakob > > 2011/5/19, Martin Koci : >> org.apache.myfaces.CHECK_ID_IN_PRODUCTION (default true) >> >> and when false: >> 1) skip duplicate id check >> 2) skip id validity check (in UIComponent.setId) >> 3) ... (something we found later) ... >> >> >> WDYT? >> >> >> Jakob Korherr píše v So 14. 05. 2011 v 12:26 +0200: >>> +1 for a MyFaces specific parameter. >>> >>> Regards, >>> Jakob >>> >>> 2011/5/11 Martin Koci : >>> > +1 for specific parameter (in one project I build view dynamically from >>> > DB and want this ids check) >>> > >>> > Gerhard Petracek píše v St 11. 05. 2011 v 07:52 +0200: >>> >> hi, >>> >> >>> >> >>> >> i would combine it -> +1 for a myfaces specific parameter which gets >>> >> evaluated in case of project-stage production. >>> >> >>> >> >>> >> regards, >>> >> gerhard >>> >> >>> >> http://www.irian.at >>> >> >>> >> Your JSF powerhouse - >>> >> JSF Consulting, Development and >>> >> Courses in English and German >>> >> >>> >> Professional Support for Apache MyFaces >>> >> >>> >> >>> >> 2011/5/11 Leonardo Uribe >>> >> Hi >>> >> >>> >> Checking the state saving algorithm I have seen that every >>> >> time >>> >> StateManager.saveView is called, it checks for duplicate ids, >>> >> scanning >>> >> the whole component tree. The documentation of >>> >> StateManager.saveView >>> >> says this: >>> >> >>> >> "...This method must also enforce the rule that, for >>> >> components with >>> >> non-null ids, all components that are descendants of the same >>> >> nearest >>> >> NamingContainer must have unique identifiers". >>> >> >>> >> Yes, that's right, but a possible optimization could be do not >>> >> do it >>> >> if project stage is production, or maybe just add a param that >>> >> disable >>> >> that stuff. >>> >> >>> >> Does that sounds good? Any objections? >>> >> >>> >> regards, >>> >> >>> >> Leonardo Uribe >>> >> >>> >> >>> > >>> > >>> > >>> >>> >>> >> >> >> > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
Re: [VOTE] release for myfaces core 2.1.0
MYFACES-3140 and MYFACES-3141 are included in the tag, but excluded from the release notes. Matt On Tue, May 24, 2011 at 1:29 PM, Leonardo Uribe wrote: > +1 > > 2011/5/24 Leonardo Uribe : >> Hi, >> >> I was running the needed tasks to get the 2.1.0 release of Apache >> MyFaces core out. >> >> The artifacts passed all TCK tests. >> >> Please note that this vote concerns all of the following parts: >> 1. Maven artifact group "org.apache.myfaces.shared" v4.1.0 [1] >> 2. Maven artifact group "org.apache.myfaces.core" v2.1.0 [1] >> >> The artifacts were deployed on nexus repo [1] and to my private >> Apache account [3] for binary and source packages. >> >> The release notes could be found at [4]. >> >> Also the clirr test does not show binary incompatibilities with myfaces-api. >> >> Please take a look at the "2.1.0" artifacts and vote! >> >> Please note: This vote is "majority approval" with a minimum of three >> +1 votes (see [3]). >> >> >> [ ] +1 for community members who have reviewed the bits >> [ ] +0 >> [ ] -1 for fatal flaws that should cause these bits not to be released, >> and why.. >> >> >> Thanks, >> Leonardo Uribe >> >> [1] >> https://repository.apache.org/content/repositories/orgapachemyfaces-003/org/apache/myfaces/ >> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes >> [3] http://people.apache.org/~lu4242/myfaces210binsrc >> [4] >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12315190 >> >
Re: [jira] [Commented] (MYFACES-3184) h:selectOneRadio cannot support f:ajax if @id not set
Pardon the bad comment; of course I was thinking of Tomahawk 1.1.11 ;) Matt On Wed, Jun 22, 2011 at 11:30 AM, Matt Benson (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/MYFACES-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053335#comment-13053335 > ] > > Matt Benson commented on MYFACES-3184: > -- > > Except... is 2.1.2 the right target version, since the attempted 2.1.1 > release was vetoed? > >> h:selectOneRadio cannot support f:ajax if @id not set >> - >> >> Key: MYFACES-3184 >> URL: https://issues.apache.org/jira/browse/MYFACES-3184 >> Project: MyFaces Core >> Issue Type: Bug >> Affects Versions: 2.1.1 >> Reporter: Matt Benson >> Assignee: Leonardo Uribe >> Fix For: 2.0.8, 2.1.2 >> >> Attachments: mf3184.tar.gz >> >> >> if the id is set, it is written to the containing table and everything works >> fine. Otherwise, the client-side DOM has no element with the id of the >> selectOneRadio component and the full effects of the ajax call (e.g. >> listener method invocation) are never carried out. Works on Mojarra. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira > > >
Re: svn commit: r1154012 - /myfaces/core/trunk/impl/pom.xml
;) I was just testing with 'provided'. Matt On Thu, Aug 4, 2011 at 3:59 PM, wrote: > Author: lu4242 > Date: Thu Aug 4 20:59:29 2011 > New Revision: 1154012 > > URL: http://svn.apache.org/viewvc?rev=1154012&view=rev > Log: > set optional="true" over impl-shared dependency > > Modified: > myfaces/core/trunk/impl/pom.xml > > Modified: myfaces/core/trunk/impl/pom.xml > URL: > http://svn.apache.org/viewvc/myfaces/core/trunk/impl/pom.xml?rev=1154012&r1=1154011&r2=1154012&view=diff > == > --- myfaces/core/trunk/impl/pom.xml (original) > +++ myfaces/core/trunk/impl/pom.xml Thu Aug 4 20:59:29 2011 > @@ -1037,6 +1037,7 @@ > > org.apache.myfaces.core.internal > myfaces-impl-shared > + true > > > > > >
Re: [COMMUNITY] MyFaces += Matt Benson
Thanks all! Matt On Tue, Aug 16, 2011 at 2:18 PM, Leonardo Uribe wrote: > Welcome! > > Leonardo > > 2011/8/16 Jakob Korherr : >> Welcome, Matt! >> >> Regards, >> Jakob >> >> 2011/8/16 Gerhard Petracek : >>> The MyFaces PMC is proud to announce a new addition to our community. >>> >>> Please welcome Matt Benson as the newest MyFaces committer! >>> Matt is an active member of the MyFaces community, especially in >>> MyFaces Core and MyFaces Extensions Validator. >>> >>> @Matt: Please add yourself to the Master-POM at >>> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml >>> >>> Welcome & regards, >>> Gerhard >>> >> >> >> >> -- >> Jakob Korherr >> >> blog: http://www.jakobk.com >> twitter: http://twitter.com/jakobkorherr >> work: http://www.irian.at >> >
Spec issue for handling of custom validator tag attributes in "wrapping" mode
(@Jakob) Can we escalate to the EG? http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 Thanks, Matt
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+1
However, let's simplify the context parameter by giving it a name
relating to JSF 2.2 compatibility. I submitted the final
implementation for Mojarra, so have every right to add the same to
MyFaces.
Matt
On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek
wrote:
> +1 for it in combination with the context parameter
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/9/21 Rudy De Busscher
>>
>> +1
>> And if we create a context parameter, it should behave by default as in
>> the JSF 2.2 Spec. If users want strict spec (2.0/2.1)behaviour they have to
>> set the parameter value.
>> regards
>> Rudy
>> On 21 September 2011 17:08, Grant Smith wrote:
>>>
>>> +1 if it's configurable in a . How about
>>> org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ?
>>>
>>> On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz wrote:
+1
Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
> +1
>
> 2011/9/21 Leonardo Uribe :
>> Hi
>>
>> More than a year ago, it was found that EL expressions like
>> #{cc.attrs.test} does not resolve its type correctly, because the
>> composite component EL resolver is not able to find the right type.
>> Instead, MapELResolver always return Object.class as type, breaking
>> composite components that use h:selectOneXXX into its internals. See
>>
>> https://issues.apache.org/jira/browse/MYFACES-2552
>>
>> The problem with this issue is we need to change the way how
>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver
>> works. JSF 2.0 spec clearly says in its section 5.6.2.2 that
>> getType()
>> for that EL resolver should return null.
>>
>> The issue was reported to the EG and a fix was included in JSF 2.2.
>> spec, see:
>>
>> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745
>>
>> but we still receive reports about the same issue (MYFACES-3311 and
>> others (last comment on MYFACES-1890) ).
>>
>> So, the current behavior even if is described by the spec is too
>> inconvenient. Note we already have some places in our implementation
>> that does not follow strictly the spec, to keep things working as
>> users expect. To follow the protocol in these cases, we need an
>> official community decision about include it in 2.0.x and 2.1.x
>> branches. Please vote:
>>
>> +1 if you want this fix included in 2.0.x and 2.1.x.
>> +0
>> -1 and the reason why if you see this could cause any problem.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> [1] http://www.apache.org/foundation/voting.html#ReleaseVotes
>>
>>>
>>>
>>>
>>> --
>>> Grant Smith - V.P. Information Technology
>>> Marathon Computer Systems, LLC.
>>>
>>
>>
>>
>> --
>> Rudy De Busscher
>> http://www.c4j.be
>>
>
>
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
The spec issue at hand relates, ultimately, to the implementation of getType() against the composite components attributes map ELResolver. The workaround presented in JIRA involves a pluggable ELResolver that delegates getType() to a ValueExpression found for a given attribute; I would venture to guess this would get the job done most of the time. The final spec for 2.2 goes farther, however, by incorporating Leo's suggestion that a composite:attribute element's 'type' attribute would also be consulted. The amended spec text describing this behavior: If the base argument to getType() is not an instance of the composite component attributes map or the property argument to getType() is not an instance of java.lang.String, return null. Otherwise, check the top level component's ValueExpression collection for an expression under the name given by the property argument to getType(). If the expression exists, call getType() on the expression. If the property argument to getType() is not empty, search the composite component's metadata for a declared type on a whose name matches the property argument to getType(). If the expression and the metadata both yield results, the metadata takes precedence ONLY if it provides a narrower result than does the expression, i.e. expression type is assignable from metadata type. Otherwise, return whichever result was available, or null. Obviously the code to implement the above will have to reside in MyFaces at some point. For this reason I would recommend the context parameter simply enable the above behavior. Matt On Wed, Sep 21, 2011 at 3:42 PM, Grant Smith wrote: > My only problem with calling it > org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY is that it's pretty generic. > What if there are other behaviors that come up in the future that also break > strict compatibility ? Do we lump them all under one umbrella ? > > How about appending _EL_RESOLVER to make it (more) specific... > > > On Wed, Sep 21, 2011 at 1:20 PM, Jakob Korherr > wrote: >> >> +1 for including the fix in 2.0.x and 2.1.x + adding >> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY >> >> Regards, >> Jakob >> >> 2011/9/21 Leonardo Uribe : >> > Hi >> > >> > @Matt Benson: Could you attach at least the fragment with the solution >> > for MYFACES-2552 ? so I can check it, create a patch for myfaces and >> > write a page on: >> > >> > https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components >> > >> > with the explanation and the solution using a custom EL resolver. That >> > would be very helpful. >> > >> > regards, >> > >> > Leonardo Uribe >> > >> > 2011/9/21 Leonardo Uribe : >> >> Hi >> >> >> >> It should be a param starting with org.apache.myfaces, like >> >> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY >> >> >> >> The important part is that by default it should be disabled, to >> >> prevent receive over and over the same report. >> >> >> >> In theory, it is possible to write a custom EL resolver that check if >> >> the base object implements >> >> javax.faces.el.CompositeComponentExpressionHolder and if that so, do >> >> the required stuff only on getType(). So, if somebody is writing a >> >> composite component that relies on this behavior, it is possible to >> >> write the fix in a portable way to both Mojarra and MyFaces (thanks to >> >> CompositeComponentExpressionHolder). >> >> >> >> Note the change does not cause any side effects, because nobody relies >> >> on the "wrong" behavior, and what user wants is components work as >> >> expected. >> >> >> >> regards, >> >> >> >> Leonardo Uribe >> >> >> >> 2011/9/21 Mark Struberg : >> >>> Not sure about that. >> >>> Does the param start with javax.faces? In this case we should rather >> >>> use an own internal one. >> >>> >> >>> Btw, if it's not in the spec even Mojarra would not be allowed to use >> >>> a proprietary parameter with "javax" >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>> >> >>> >> >>> - Original Message - >> >>>> From: Matt Benson >> >>>> To: MyFaces Development >> >>>> Cc: >> >>>> Sent: Wednesday, September 21, 2011 6:29 PM >> >>
Re: [COMMUNITY] MyFaces += Michael Kurz
+1: Congratulations, Michael. Matt On Fri, Sep 30, 2011 at 4:48 AM, Jakob Korherr wrote: > Hi Michael, > > Congrats! > > Regards, > Jakob > > 2011/9/30 Martin Marinschek : >> Hi Michael, >> >> congratulations! >> >> best regards, >> >> Martin >> >> On Fri, Sep 30, 2011 at 9:09 AM, Werner Punz wrote: >>> Am 9/30/11 8:11 AM, schrieb Gerhard Petracek: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Michael Kurz as the newest MyFaces committer! Michael is an active member of the MyFaces community, especially in MyFaces Core. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome & regards, Gerhard >>> >>> Congratulations Michael, well deserved. >>> >>> >>> >>> >>> werner >>> >>> >>> >> >> >> >> -- >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> > > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at >
Re: [DISCUSS] internal incubator
Guys, Just a note on the concept of a mini-incubator: been there, done that [1]. The basic available approaches are noted at [2] (search for "Some possible solutions"). Matt [1] http://markmail.org/message/n3t7lksceuplh45r [2] http://markmail.org/message/r6ffmmyh6pxnn6nd On Thu, Oct 27, 2011 at 4:32 PM, Mark Struberg wrote: > > > +1 > > LieGrue, > strub > > > >> >>From: Gerhard Petracek >>To: MyFaces Development >>Sent: Thursday, October 27, 2011 11:18 PM >>Subject: [DISCUSS] internal incubator >> >> >>hi @ all, >> >> >>this is a new thread based on [1]. >> >> >>the idea of an internal incubator: >> >> >>esp. gsoc projects (for myfaces) could move pretty easy to myfaces. >>as soon as we see that there is a community for it, we can promote such a >>project (as an own sub-project or as a module of an existing sub-project). >>after moving a project to this incubator, we shouldn't wait that long with >>the final discussion about keeping or dropping it (e.g. one quarter). >> >> >>potential candidates right now are: >> - codi-rad >> - html5components >> - manila >> >> >>regards, >>gerhard >> >> >>[1] http://mail-archives.apache.org/mod_mbox/myfaces-dev/201110.mbox/%3CCAGJtJfHBrOvO5m-isDvPSWODWkPKQjVfnsqK1rKYd%2BDEP5duzw%40mail.gmail.com%3E >> >>http://www.irian.at >> >>Your JSF powerhouse - >>JSF Consulting, Development and >>Courses in English and German >> >>Professional Support for Apache MyFaces >> >> >> >
Re: Inclusion of MyFace API in javaee-api jar
On Fri, Oct 28, 2011 at 2:46 PM, David Blevins wrote: > Quick question on the org.apache.myfaces.core:myfaces-api jar. > > Is it tied to MyFaces in some way? Guessing the answer is, yes, as it is > labeled "myfaces-api" and not something more generic like "faces-api" > > If the answer is, no, then the follow up is how often does its contents > change? > > If it is stable and only changed once in a while, we might include it in the > javaee-api jar we produce from OpenEJB/TomEE. We don't include JavaMail for > example as it really isn't an API but an actual implementation. Seems like > that is the case here. Nail on the head and all that. :) Matt > > > -David > >
Re: [VOTE] Internal Incubator
On Wed, Nov 2, 2011 at 6:32 AM, Matthias Wessendorf wrote: > FWIW: > > -1 > > why introducing yet another level of "incubation" process ? > I find it (very) problematic trying to be in some sort of > "competition" w/ the Apache Incubator... > (even if the discussed targets here are JSF specific) As I have attempted to point out elsewhere via email links (which presumably went unfollowed), not only is this "problematic"; per Incubator PMC consensus it is downright unacceptable. You simply can't have a mini-incubator so complete that it makes sense even to use the *name* "incubator". PLEASE read [1] for background, or skip directly to [2] (search for "Some possible solutions") to know what IS acceptable. There is no need for MyFaces to rehash my experiences on Commons' behalf two-plus years ago. [1] http://markmail.org/message/n3t7lksceuplh45r [2] http://markmail.org/message/r6ffmmyh6pxnn6nd Matt > > Why not simply "moving" future (MyFaces) GSoC directly to the Apache > Labs project ([1])?! > For there, just start coding and releasing (alphas etc). The new > release process is straightforward > and not heavyweight - so (alpha) releases are cheap. > > -M > > [1] http://labs.apache.org/ > > On Tue, Nov 1, 2011 at 11:28 AM, Bernd Bohmann > wrote: >> Ok, >> >> if there is no real difference between Apache Incubator and Apache >> MyFaces Incubator, >> I have to change my vote to >> >> -1 >> >> especially a have a problem with: >> >> All code donations from external organisations and >> existing external projects wishing to join MyFaces enter through the >> MyFaces-Incubator. >> >> This is the Apache Incubator role. >> >> Regards >> >> Bernd >> >> >> On Tue, Nov 1, 2011 at 10:25 AM, Gerhard Petracek >> wrote: >>> hi bart, >>> >>> as mentioned [1] by mark it's also about ip clearance [2]. >>> >>> regards, >>> gerhard >>> >>> [1] >>> http://mail-archives.apache.org/mod_mbox/myfaces-dev/201110.mbox/%3c1319274310.93350.yahoomail...@web27807.mail.ukl.yahoo.com%3E >>> [2] http://incubator.apache.org/ip-clearance/index.html >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >>> >>> 2011/11/1 Bart Kummel +1 for the idea! I agree with Bernd about the name. For me, "incubator" is also associated with rules and legal stuff. We should encourage people to contribute, instead of scaring them away. "Sandbox" or "labs" sounds encouraging and accessible. But perhaps we should discuss/vote the name in another thread and first focus on the idea... Best regards, Bart Kummel On Tue, Nov 1, 2011 at 01:36, Gerhard Petracek wrote: > > Hi, > > in order to check if there is a community for a new sub-project (esp. > GSoC projects for MyFaces), we discussed [1] the introduction of an > internal incubator. > We would release such projects early and e.g. after a quarter we > decide if we keep and promote a project (as a sub-project or a module > of an existing sub-project) or if we drop it. > > Please vote: > > [+1] I like the idea > [0] I'm not convinced but I'm ok with it > [-1] I don't agree > > Regards, > Gerhard > > [1] http://markmail.org/message/d7oogfabvliwn7fg >>> >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
Trinidad versions
Website shows 2.0.0 as latest; JIRA seems to agree, so should http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1 exist? Matt
Re: [VOTE] Release of Extensions Validator 1.2.5 and 2.0.5
+1 Matt On Sun, Dec 18, 2011 at 12:58 PM, Hazem Saleh wrote: > ++1 > > > On Sun, Dec 18, 2011 at 1:09 AM, Gerhard Petracek > wrote: >> >> +1 >> >> regards, >> gerhard >> >> >> >> >> 2011/12/18 Gerhard Petracek >>> >>> Hi, >>> >>> I was running the needed tasks to get the 5th release of Apache MyFaces >>> Extensions Validator out. >>> The artifacts are deployed to Nexus [1-2]. >>> >>> These 2 releases contain the following modules for JSF 1.2, JSF 2.0: >>> - ExtVal Core >>> - ExtVal Property-Validation >>> - ExtVal Bean-Validation (Integration + additional features for using >>> JSR 303 with JSF 1.2 and 2.x) >>> - Trinidad-Support-Module >>> - Generic-Support-Module >>> >>> Please take a look at the 1.2.5 and 2.0.5 artifacts and vote! >>> >>> Please note: >>> This vote is "majority approval" with a minimum of three +1 votes (see >>> [3]). >>> >>> >>> [ ] +1 for community members who have reviewed the bits >>> [ ] +0 >>> [ ] -1 for fatal flaws that should cause these bits not to be released, >>> and why.. >>> >>> >>> Thanks, >>> Gerhard >>> >>> [1] >>> http://repository.apache.org/content/repositories/orgapachemyfaces-363/org/apache/myfaces/extensions/validator/ >>> [2] >>> http://repository.apache.org/content/repositories/orgapachemyfaces-364/org/apache/myfaces/extensions/validator/ >>> [3] http://www.apache.org/foundation/voting.html#ReleaseVotes >> >> > > > > -- > Hazem Ahmed Saleh Ahmed > > Author of (The Definitive Guide to Apache MyFaces and Facelets): > http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 > http://www.amazon.com/-/e/B002M052KY > > Visualize and share your social networks 2D and 3D: > http://www.mapmysocial.com >
Re: Sick leave
Hi Werner, Sorry to hear that you are having health problems. I wish you a speedy recovery. Matt On Fri, Jan 20, 2012 at 2:26 AM, Werner Punz wrote: > I am currently on sick leave, which means, that I will be able to monitor > the mailinglist about once per day, but bugfixes and implementation work > will be postponed for a few weeks. The codebase for the jsf.js part is in an > excellent state so it should be ok for 2-3 new releases and if something > severe erupts in that part I will give consulting to whoever wants to tackle > the task. > > The Ext-Scripting codebase has been now fixed up so that it works with the > latest myfaces implementations, a new release will be pending as soon as I > am out of the hospital. > > I will be back in the old state and working again for MyFaces in 2-3 weeks. > > > Werner >
Re: MockCompositeValueExpression
On Fri, Feb 24, 2012 at 5:10 PM, Kito Mann wrote:
> Does anyone know why the constructor to MockCompositeValueExpression in
> MyFaces-Tests calls the superclass's constructor like so?
>
> super("#{}", expectedType);
>
> I'm thinking this is a bug, and that it should pass the actual expression:
>
> super(expression, expectedType);
>
> Let me know if I'm not missing something, and I'll create a JIRA issue.
Kito,
The super constructor will attempt to parse what it is given, but
since a composite expression may embed multiple #{...} constructs
among literal text sequences, this parsing would fail. It is for this
reason that the super constructor is passed a dummy expression.
Thanks,
Matt
> ___
>
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
> jsfcentral
> +1 203-404-4848 x3
>
> * Listen to the latest headlines in the JSF and Java EE
> newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
Re: MockCompositeValueExpression
On Fri, Feb 24, 2012 at 5:23 PM, Kito Mann wrote:
> On Fri, Feb 24, 2012 at 6:21 PM, Matt Benson wrote:
>>
>> On Fri, Feb 24, 2012 at 5:10 PM, Kito Mann wrote:
>> > Does anyone know why the constructor to MockCompositeValueExpression in
>> > MyFaces-Tests calls the superclass's constructor like so?
>> >
>> > super("#{}", expectedType);
>> >
>> > I'm thinking this is a bug, and that it should pass the actual
>> > expression:
>> >
>> > super(expression, expectedType);
>> >
>> > Let me know if I'm not missing something, and I'll create a JIRA issue.
>>
>> Kito,
>> The super constructor will attempt to parse what it is given, but
>> since a composite expression may embed multiple #{...} constructs
>> among literal text sequences, this parsing would fail. It is for this
>> reason that the super constructor is passed a dummy expression.
>>
>
> This makes sense. However, isLiteral() is returning false in this case when
> it shouldn't, and I believe getExpressionString() is hardcoded to "#{}" as
> well.
>
Ah, then it sounds like the patch should compensate for these. :)
Matt
>>
>> Thanks,
>> Matt
>>
>> > ___
>> >
>> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> > consulting
>> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> > twitter:
>> > jsfcentral
>> > +1 203-404-4848 x3
>> >
>> > * Listen to the latest headlines in the JSF and Java EE
>> >
>> > newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
>> > * Sign up for the JSFCentral newsletter:
>> > http://oi.vresp.com/?fid=ac048d0e17
>> >
>
>
IRC abuse
Anyone with ops around to kick/ban these jokers? Matt
Re: Wiki Spam
I agree that it's getting overwhelming lately. MyFaces is the last ASF Moin wiki I get updates from where these measures haven't been taken. +1 to get this set up. Matt On Fri, Apr 19, 2013 at 3:19 PM, Mike Kienenberger wrote: > My recommendation is that we set up an AdminGroup, probably with all > committers in it. > > Then we add additional people to the ContributorsGroup as desired. > > > http://wiki.apache.org/general/WikiFrequentlyAskedQuestions > > http://wiki.apache.org/general/OurWikiFarm > = > per wiki access control - tighten your wiki just a little, benefit just a > lot > > Long sub-title for a fairly long subject. > > The MoinMoin wiki is very configurable, more so than some might think. > Of course, wikis are meant to be open, for complete and utter open > collaboration. That is appreciated. However, there are some that would > like a balance between open wiki and having to spend time cleaning up > spam each week. Times change, and the reality is, spammers are here > and in greater numbers than before. What can we do? Well, here is a > suggestion - and one that can be easily implemented and takes but 2 > minutes (for infra) to set up. > > Have your project wiki editable only by a custom trusted group - that > need not be committers only - it can in fact still be anybody who > wants to edit your wiki, they just need to ask one time for edit > access and thats it. Is this an incovenience? To ask once for access, > I don't think so. After all as a potential contributor to your wiki > you (project) will already be conversing with the potential > contributor via the mailing lists right? How much pain is it to add > someone to the custom trusted group once it has been set up? , no pain > at all, a member of the projects AdminGroup edits one wiki page, adds > the users WikiuserName to the bottom of the list and save the page! 10 > seconds maybe and your done. For the amount of times you will have to > do that as opposed to the amount of times you spend cleaning up spam - > you work out which is better. > > The spamassassin wiki is a good example - those in the project wikis > AdminGroup can add folks to the projects ContributorsGroup and that's > it. How much spam has spamassassin received since this was setup ? > Zero, Zilch, Nil, Nada. > > Remember also, any page can have its own access control which > overrides and per wiki and per farm defaults - This page does just > that, as does LocalBadContent and BadContent pages. > = > > > > On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger > wrote: > > Probably it's time to enable some kind of protection for the wiki. > > > > I've been hoping to avoid that, but the amount of spam the past two > > weeks has finally exceeded my willingness to continue fixing by hand. > > > > Is anyone who is subscribed to infrastructure willing to look into > > this? If no takers, I guess I'll sign up and see what can be done. > > > > > > On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici > > wrote: > >> Hi, > >> > >> Does anyone know how can I unsubscribe from wiki as it is full of spam > >> everyday. > >> > >> Thanks, > >> > >> Cagatay Civici > >> PrimeFaces Lead > >> www.primefaces.org > >> >
Re: Wiki Spam
Mike, as far as I know I have been the other guy deleting spam pages. You can add me as an administrator if you like, id MattBenson. Matt On Wed, Apr 24, 2013 at 7:45 AM, Mike Kienenberger wrote: > I don't have time to do much testing of this right now, but Gavin has > reconfigured our wiki. > > I've added Leonardo as an administrator as his is the only other wiki > id that I know. > > I searched my mailbox for recent wiki contributors and added them to > the ContributorsGroup. > > If you send me your wiki id, I'll add you as either a contributor or > administrator as desired when I get back later today. > It'd be nice to have a few more administrators listed just in case. > > > > > On Tue, Apr 23, 2013 at 11:22 AM, Matt Cooper wrote: > > Thank you Mike for getting this going! > > > > > > On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger > > wrote: > >> > >> I've requested Infra to help us make this happen. > >> > >> https://issues.apache.org/jira/browse/INFRA-6191 > >> > >> On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger > > >> wrote: > >> > So I've been poking around for a while to try to set up > >> > AdminGroup/ContributorsGroup, and I know what the pages should look > >> > like. > >> > > >> > But I don't currently have the permissions to make the changes myself. > >> > > >> > http://wiki.apache.org/general/HowToBeWikiAdministrator > >> > > >> > Does anyone here already have Wiki Administrator permissions? > >> > > >> > Or apsite permission on minotaur? > >> > > >> > If not, I'll need to contact infrastructure. > >> > > >> > On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger < > mkien...@gmail.com> > >> > wrote: > >> >> My recommendation is that we set up an AdminGroup, probably with all > >> >> committers in it. > >> >> > >> >> Then we add additional people to the ContributorsGroup as desired. > >> >> > >> >> > >> >> http://wiki.apache.org/general/WikiFrequentlyAskedQuestions > >> >> > >> >> http://wiki.apache.org/general/OurWikiFarm > >> >> = > >> >> per wiki access control - tighten your wiki just a little, benefit > just > >> >> a lot > >> >> > >> >> Long sub-title for a fairly long subject. > >> >> > >> >> The MoinMoin wiki is very configurable, more so than some might > think. > >> >> Of course, wikis are meant to be open, for complete and utter open > >> >> collaboration. That is appreciated. However, there are some that > would > >> >> like a balance between open wiki and having to spend time cleaning up > >> >> spam each week. Times change, and the reality is, spammers are here > >> >> and in greater numbers than before. What can we do? Well, here is a > >> >> suggestion - and one that can be easily implemented and takes but 2 > >> >> minutes (for infra) to set up. > >> >> > >> >> Have your project wiki editable only by a custom trusted group - that > >> >> need not be committers only - it can in fact still be anybody who > >> >> wants to edit your wiki, they just need to ask one time for edit > >> >> access and thats it. Is this an incovenience? To ask once for access, > >> >> I don't think so. After all as a potential contributor to your wiki > >> >> you (project) will already be conversing with the potential > >> >> contributor via the mailing lists right? How much pain is it to add > >> >> someone to the custom trusted group once it has been set up? , no > pain > >> >> at all, a member of the projects AdminGroup edits one wiki page, adds > >> >> the users WikiuserName to the bottom of the list and save the page! > 10 > >> >> seconds maybe and your done. For the amount of times you will have to > >> >> do that as opposed to the amount of times you spend cleaning up spam > - > >> >> you work out which is better. > >> >> > >> >> The spamassassin wiki is a good example - those in the project wikis > >> >> AdminGroup can add folks to the projects ContributorsGroup and that's > >> >> it. How much spam has spamassassin received since this was setup ? > >> >> Zero, Zilch, Nil, Nada. > >> >> > >> >> Remember also, any page can have its own access control which > >> >> overrides and per wiki and per farm defaults - This page does just > >> >> that, as does LocalBadContent and BadContent pages. > >> >> = > >> >> > >> >> > >> >> > >> >> On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger < > mkien...@gmail.com> > >> >> wrote: > >> >>> Probably it's time to enable some kind of protection for the wiki. > >> >>> > >> >>> I've been hoping to avoid that, but the amount of spam the past two > >> >>> weeks has finally exceeded my willingness to continue fixing by > hand. > >> >>> > >> >>> Is anyone who is subscribed to infrastructure willing to look into > >> >>> this? If no takers, I guess I'll sign up and see what can be done. > >> >>> > >> >>> > >> >>> On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici > >> >>> wrote: > >> Hi, > >> > >> Does anyone know how can I unsubscribe from wiki as it is full of > >> spam > >> everyday. > >> > >>
[jira] [Created] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
NullPointerException in
UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot
subscribed to PostAddToViewEvent
--
Key: MYFACES-3119
URL: https://issues.apache.org/jira/browse/MYFACES-3119
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.5
Reporter: Matt Benson
As reported in MYFACES-2466 (whose summary I copied here), I am encountering
the NPE on the access of {{holderList}} in what is currently line 1917 of
{{UIComponentBase}} whenever I use a {{ComponentSystemEventListener}} on
{{UIViewRoot}}. Specifically I am subscribing to {{PreRenderViewEvent}} and
the problem occurs restoring the view regardless of whether I unsubscribe the
listener e.g. after {{RENDER_RESPONSE}}.
More information:
{{_systemEventListenerClassMap}} is {{null}} when the method is called, thus
the map is reinstantiated so of course the value looked up and assigned to
{{holderList}} is {{null}}.
Now I have to go use Mojarra until this is fixed. :(
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3119: - Status: Patch Available (was: Open) > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-3119 > URL: https://issues.apache.org/jira/browse/MYFACES-3119 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.5 >Reporter: Matt Benson > Attachments: mf3119.tar.gz, mf3119.tar.gz > > > As reported in MYFACES-2466 (whose summary I copied here), I am encountering > the NPE on the access of holderList in what is currently line 1917 of > UIComponentBase whenever I use a ComponentSystemEventListener on UIViewRoot. > Specifically I am subscribing to PreRenderViewEvent and the problem occurs > restoring the view regardless of whether I unsubscribe the listener e.g. > after RENDER_RESPONSE. > More information: > _systemEventListenerClassMap is null when the method is called, thus the map > is reinstantiated so of course the value looked up and assigned to holderList > is null. > Now I have to go use Mojarra until this is fixed. :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027023#comment-13027023 ] Matt Benson commented on MYFACES-3119: -- Actually Jakob's "ugly fix" patch was not granted license for inclusion. Realistically his committership + CLA are probably enough however. > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-3119 > URL: https://issues.apache.org/jira/browse/MYFACES-3119 > Project: MyFaces Core > Issue Type: Bug > Components: General > Affects Versions: 2.0.5 >Reporter: Matt Benson > Attachments: mf3119.patch.txt, mf3119.tar.gz, mf3119.tar.gz > > > As reported in MYFACES-2466 (whose summary I copied here), I am encountering > the NPE on the access of holderList in what is currently line 1917 of > UIComponentBase whenever I use a ComponentSystemEventListener on UIViewRoot. > Specifically I am subscribing to PreRenderViewEvent and the problem occurs > restoring the view regardless of whether I unsubscribe the listener e.g. > after RENDER_RESPONSE. > More information: > _systemEventListenerClassMap is null when the method is called, thus the map > is reinstantiated so of course the value looked up and assigned to holderList > is null. > Now I have to go use Mojarra until this is fixed. :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027069#comment-13027069 ] Matt Benson commented on MYFACES-3119: -- That's very possible, as Jakob himself called it an "ugly" patch. Without being very familiar with the code, I just applied the patch that was available to see if it worked for me. > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-3119 > URL: https://issues.apache.org/jira/browse/MYFACES-3119 > Project: MyFaces Core > Issue Type: Bug > Components: General > Affects Versions: 2.0.5 >Reporter: Matt Benson > Attachments: mf3119.patch.txt, mf3119.tar.gz, mf3119.tar.gz > > > As reported in MYFACES-2466 (whose summary I copied here), I am encountering > the NPE on the access of holderList in what is currently line 1917 of > UIComponentBase whenever I use a ComponentSystemEventListener on UIViewRoot. > Specifically I am subscribing to PreRenderViewEvent and the problem occurs > restoring the view regardless of whether I unsubscribe the listener e.g. > after RENDER_RESPONSE. > More information: > _systemEventListenerClassMap is null when the method is called, thus the map > is reinstantiated so of course the value looked up and assigned to holderList > is null. > Now I have to go use Mojarra until this is fixed. :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027167#comment-13027167 ] Matt Benson commented on MYFACES-3119: -- Leo: thanks for the response. I am not clear on your solution, however. Note that the PhaseListener is only used to apply the ComponentSystemEventListener to the view, so in my opinion I *am* using a PreRenderViewEvent instead of a PhaseListener. Is it your contention that the subscribe/unsubscribe parts of the UIComponent(Base) API should *not* be used directly by Java code? That seems wrong to me. Without getting too deep into partial state and delta changes, with which I am yet not so familiar, my comprehension of the *immediate* cause of the NPE is that the method in question: * checks instance variable _systemEventListenerClassMap, creating a new instance if null * assumes that the map will contain a non-null value for every key in the passed-in map How can the newly created instance be expected to have the same keyset as the previously saved map? > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-3119 > URL: https://issues.apache.org/jira/browse/MYFACES-3119 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Leonardo Uribe > Attachments: mf3119.patch.txt, mf3119.tar.gz, mf3119.tar.gz > > > As reported in MYFACES-2466 (whose summary I copied here), I am encountering > the NPE on the access of holderList in what is currently line 1917 of > UIComponentBase whenever I use a ComponentSystemEventListener on UIViewRoot. > Specifically I am subscribing to PreRenderViewEvent and the problem occurs > restoring the view regardless of whether I unsubscribe the listener e.g. > after RENDER_RESPONSE. > More information: > _systemEventListenerClassMap is null when the method is called, thus the map > is reinstantiated so of course the value looked up and assigned to holderList > is null. > Now I have to go use Mojarra until this is fixed. :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3119) NullPointerException in UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot subscribed to PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027217#comment-13027217 ] Matt Benson commented on MYFACES-3119: -- Leo: Thanks for your patient explanation. I am beginning to understand it. However, I would then suggest that perhaps there might be a more graceful failure available rather than an unqualified NPE. This would also help avoid users mistakenly thinking there is a bug. > NullPointerException in > UIComponentBase.restoreDeltaSystemEventListenerClassMap() when UIViewRoot > subscribed to PostAddToViewEvent > -- > > Key: MYFACES-3119 > URL: https://issues.apache.org/jira/browse/MYFACES-3119 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Leonardo Uribe > Attachments: mf3119-fix-viewhandler.zip, mf3119.patch.txt, > mf3119.tar.gz, mf3119.tar.gz > > > As reported in MYFACES-2466 (whose summary I copied here), I am encountering > the NPE on the access of holderList in what is currently line 1917 of > UIComponentBase whenever I use a ComponentSystemEventListener on UIViewRoot. > Specifically I am subscribing to PreRenderViewEvent and the problem occurs > restoring the view regardless of whether I unsubscribe the listener e.g. > after RENDER_RESPONSE. > More information: > _systemEventListenerClassMap is null when the method is called, thus the map > is reinstantiated so of course the value looked up and assigned to holderList > is null. > Now I have to go use Mojarra until this is fixed. :( -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3125) ValidatorTagHandlerDelegate does not invoke next handler in partial processing mode, which damages the component structure
ValidatorTagHandlerDelegate does not invoke next handler in partial processing mode, which damages the component structure -- Key: MYFACES-3125 URL: https://issues.apache.org/jira/browse/MYFACES-3125 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson In my particular example (which I may or may not be able to extract and reproduce), I have: ... In this example, the form's children are marked for deletion; then, when ValidatorTHDelegate sees that the parent is not a new component, it bails out, thus failing to invoke the next handler and re-add the child components. When the deletion is finalized the form is left with no children, which incidentally makes it impossible to complete the AJAX request as designed, since the component to re-render no longer exists! I believe this would only be a problem in wrapping mode. I have verified that removing the validateBean tag causes the form's structure to be preserved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3125) ValidatorTagHandlerDelegate does not invoke next handler in partial processing mode, which damages the component structure
[ https://issues.apache.org/jira/browse/MYFACES-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030054#comment-13030054 ] Matt Benson commented on MYFACES-3125: -- I hadn't yet had any luck reproducing this in a submittable example project, but hoped that my initial description would be enough to go on. Thanks for the fix! > ValidatorTagHandlerDelegate does not invoke next handler in partial > processing mode, which damages the component structure > -- > > Key: MYFACES-3125 > URL: https://issues.apache.org/jira/browse/MYFACES-3125 > Project: MyFaces Core > Issue Type: Bug >Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.6, 2.1.0 > > > In my particular example (which I may or may not be able to extract and > reproduce), I have: > > > > ... > > > In this example, the form's children are marked for deletion; then, when > ValidatorTHDelegate sees that the parent is not a new component, it bails > out, thus failing to invoke the next handler and re-add the child components. > When the deletion is finalized the form is left with no children, which > incidentally makes it impossible to complete the AJAX request as designed, > since the component to re-render no longer exists! I believe this would only > be a problem in wrapping mode. I have verified that removing the > validateBean tag causes the form's structure to be preserved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3125) ValidatorTagHandlerDelegate does not invoke next handler in partial processing mode, which damages the component structure
[ https://issues.apache.org/jira/browse/MYFACES-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030065#comment-13030065 ] Matt Benson commented on MYFACES-3125: -- I plan to do a build from trunk later and check; will report back. > ValidatorTagHandlerDelegate does not invoke next handler in partial > processing mode, which damages the component structure > -- > > Key: MYFACES-3125 > URL: https://issues.apache.org/jira/browse/MYFACES-3125 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.6, 2.1.0 > > > In my particular example (which I may or may not be able to extract and > reproduce), I have: > > > > ... > > > In this example, the form's children are marked for deletion; then, when > ValidatorTHDelegate sees that the parent is not a new component, it bails > out, thus failing to invoke the next handler and re-add the child components. > When the deletion is finalized the form is left with no children, which > incidentally makes it impossible to complete the AJAX request as designed, > since the component to re-render no longer exists! I believe this would only > be a problem in wrapping mode. I have verified that removing the > validateBean tag causes the form's structure to be preserved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3132) javax.faces.context.ResponseWriterWrapper implementation is overdone
javax.faces.context.ResponseWriterWrapper implementation is overdone Key: MYFACES-3132 URL: https://issues.apache.org/jira/browse/MYFACES-3132 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson When using IceFaces an NPE is encountered when one of the lower-level Writer calls is made against its DomResponseWriter (specifically this was a result of HtmlRendererUtils.renderSelectOptions() calling writer.write(TABULATOR)). This is because java.io.Writer delegates all forms of #write() back to the abstract write(char[], int, int) variant. MyFaces' version of ResponseWriterWrapper implements write(int) directly, whereas the spec actually not does declare this method as being implemented here and thus allows the default implementation from Writer to delegate to the char[], int, int version. Since the MyFaces version calls getWrapped().write(int), an NPE is thrown that would be avoided if IceFaces were permitted to proceed through the call sequence as implicitly promised by the spec. True implementation of the spec requires deleting each of: * append(char) * append(CharSequence) * append(CharSequence, int, int) * write(char[]) * write(int) * write(String) * write(String, int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3132) javax.faces.context.ResponseWriterWrapper implementation is overdone
[ https://issues.apache.org/jira/browse/MYFACES-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030904#comment-13030904 ] Matt Benson commented on MYFACES-3132: -- I do feel it is important to distinguish the fact that MyFaces' implementation of the javax.faces APIs should _exactly_ implement the specification, making the implemention of these methods a deficit rather than a benefit. This would likely almost never be the case with any "normal" situation. In any event, thanks for addressing this! > javax.faces.context.ResponseWriterWrapper implementation is overdone > > > Key: MYFACES-3132 > URL: https://issues.apache.org/jira/browse/MYFACES-3132 > Project: MyFaces Core > Issue Type: Bug >Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.6, 2.1.0 > > Attachments: MYFACES-3132-1.patch > > > When using IceFaces an NPE is encountered when one of the lower-level Writer > calls is made against its DomResponseWriter (specifically this was a result > of HtmlRendererUtils.renderSelectOptions() calling writer.write(TABULATOR)). > This is because java.io.Writer delegates all forms of #write() back to the > abstract write(char[], int, int) variant. MyFaces' version of > ResponseWriterWrapper implements write(int) directly, whereas the spec > actually not does declare this method as being implemented here and thus > allows the default implementation from Writer to delegate to the char[], int, > int version. Since the MyFaces version calls getWrapped().write(int), an NPE > is thrown that would be avoided if IceFaces were permitted to proceed through > the call sequence as implicitly promised by the spec. True implementation of > the spec requires deleting each of: > * append(char) > * append(CharSequence) > * append(CharSequence, int, int) > * write(char[]) > * write(int) > * write(String) > * write(String, int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3125) ValidatorTagHandlerDelegate does not invoke next handler in partial processing mode, which damages the component structure
[ https://issues.apache.org/jira/browse/MYFACES-3125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031417#comment-13031417 ] Matt Benson commented on MYFACES-3125: -- Took awhile for me to get back to this, but yes--latest 2.1.0-SNAPSHOT fixes my problem. Thanks Leo! > ValidatorTagHandlerDelegate does not invoke next handler in partial > processing mode, which damages the component structure > -- > > Key: MYFACES-3125 > URL: https://issues.apache.org/jira/browse/MYFACES-3125 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.6, 2.1.0 > > > In my particular example (which I may or may not be able to extract and > reproduce), I have: > > > > ... > > > In this example, the form's children are marked for deletion; then, when > ValidatorTHDelegate sees that the parent is not a new component, it bails > out, thus failing to invoke the next handler and re-add the child components. > When the deletion is finalized the form is left with no children, which > incidentally makes it impossible to complete the AJAX request as designed, > since the component to re-render no longer exists! I believe this would only > be a problem in wrapping mode. I have verified that removing the > validateBean tag causes the form's structure to be preserved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3132) javax.faces.context.ResponseWriterWrapper implementation is overdone
[ https://issues.apache.org/jira/browse/MYFACES-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032006#comment-13032006 ] Matt Benson commented on MYFACES-3132: -- I think the problem that was caused by this has indeed been solved. This, however, seems to be only the tip of the iceberg wrt making Icefaces compatible with MyFaces, but we shall see. Thanks! > javax.faces.context.ResponseWriterWrapper implementation is overdone > > > Key: MYFACES-3132 > URL: https://issues.apache.org/jira/browse/MYFACES-3132 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.6, 2.1.0 > > Attachments: MYFACES-3132-1.patch > > > When using IceFaces an NPE is encountered when one of the lower-level Writer > calls is made against its DomResponseWriter (specifically this was a result > of HtmlRendererUtils.renderSelectOptions() calling writer.write(TABULATOR)). > This is because java.io.Writer delegates all forms of #write() back to the > abstract write(char[], int, int) variant. MyFaces' version of > ResponseWriterWrapper implements write(int) directly, whereas the spec > actually not does declare this method as being implemented here and thus > allows the default implementation from Writer to delegate to the char[], int, > int version. Since the MyFaces version calls getWrapped().write(int), an NPE > is thrown that would be avoided if IceFaces were permitted to proceed through > the call sequence as implicitly promised by the spec. True implementation of > the spec requires deleting each of: > * append(char) > * append(CharSequence) > * append(CharSequence, int, int) > * write(char[]) > * write(int) > * write(String) > * write(String, int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3135) Correct spelling errors in HtmlResponseStateManager exception messages
Correct spelling errors in HtmlResponseStateManager exception messages -- Key: MYFACES-3135 URL: https://issues.apache.org/jira/browse/MYFACES-3135 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.0-SNAPSHOT Reporter: Matt Benson Attachments: MF-3135.patch.txt patch forthcoming -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3135) Correct spelling errors in HtmlResponseStateManager exception messages
[ https://issues.apache.org/jira/browse/MYFACES-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3135: - Status: Patch Available (was: Open) > Correct spelling errors in HtmlResponseStateManager exception messages > -- > > Key: MYFACES-3135 > URL: https://issues.apache.org/jira/browse/MYFACES-3135 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.0-SNAPSHOT > Reporter: Matt Benson > Attachments: MF-3135.patch.txt > > > patch forthcoming -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3135) Correct spelling errors in HtmlResponseStateManager exception messages
[ https://issues.apache.org/jira/browse/MYFACES-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3135: - Resolution: Cannot Reproduce Status: Resolved (was: Patch Available) code was removed for MYFACES-3138 > Correct spelling errors in HtmlResponseStateManager exception messages > -- > > Key: MYFACES-3135 > URL: https://issues.apache.org/jira/browse/MYFACES-3135 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.0-SNAPSHOT > Reporter: Matt Benson > Attachments: MF-3135.patch.txt > > > patch forthcoming -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3140) FacesMessage.VALUES is not ordered properly
FacesMessage.VALUES is not ordered properly --- Key: MYFACES-3140 URL: https://issues.apache.org/jira/browse/MYFACES-3140 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Attachments: MF-3140.patch.txt Per spec this list should be ordered as dictated by the ordinal values of the FacesMessage.Severity (emulated) enum values. Attaching testcase proving it is not (additionally testing contract of VALUES_MAP) and patch to address issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3140) FacesMessage.VALUES is not ordered properly
[ https://issues.apache.org/jira/browse/MYFACES-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3140: - Status: Patch Available (was: Open) > FacesMessage.VALUES is not ordered properly > --- > > Key: MYFACES-3140 > URL: https://issues.apache.org/jira/browse/MYFACES-3140 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson > Attachments: MF-3140.patch.txt > > > Per spec this list should be ordered as dictated by the ordinal values of the > FacesMessage.Severity (emulated) enum values. Attaching testcase proving it > is not (additionally testing contract of VALUES_MAP) and patch to address > issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3141) FacesMessage implements Serializable but cannot be serialized
[ https://issues.apache.org/jira/browse/MYFACES-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3141: - Status: Patch Available (was: Open) > FacesMessage implements Serializable but cannot be serialized > - > > Key: MYFACES-3141 > URL: https://issues.apache.org/jira/browse/MYFACES-3141 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson > > This is due, of course, to > http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-921, but the simple > interim solution is a custom serialization approach. Attaching a patch to > implement and test same, which necessarily incorporates changes from > MYFACES-3140 as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3141) FacesMessage implements Serializable but cannot be serialized
FacesMessage implements Serializable but cannot be serialized - Key: MYFACES-3141 URL: https://issues.apache.org/jira/browse/MYFACES-3141 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson This is due, of course, to http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-921, but the simple interim solution is a custom serialization approach. Attaching a patch to implement and test same, which necessarily incorporates changes from MYFACES-3140 as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3141) FacesMessage implements Serializable but cannot be serialized
[ https://issues.apache.org/jira/browse/MYFACES-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032547#comment-13032547 ] Matt Benson commented on MYFACES-3141: -- Incidentally, due to Icefaces' adding FacesMessages to the viewMap (IIRC), this is another large blocker to Icefaces compatibility. > FacesMessage implements Serializable but cannot be serialized > - > > Key: MYFACES-3141 > URL: https://issues.apache.org/jira/browse/MYFACES-3141 > Project: MyFaces Core > Issue Type: Bug >Reporter: Matt Benson > Attachments: MF-3141.patch.txt > > > This is due, of course, to > http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-921, but the simple > interim solution is a custom serialization approach. Attaching a patch to > implement and test same, which necessarily incorporates changes from > MYFACES-3140 as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EXTVAL-131) test-modules should publish source jars
[ https://issues.apache.org/jira/browse/EXTVAL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated EXTVAL-131: --- Status: Patch Available (was: Open) > test-modules should publish source jars > --- > > Key: EXTVAL-131 > URL: https://issues.apache.org/jira/browse/EXTVAL-131 > Project: MyFaces Extensions Validator > Issue Type: Improvement > Reporter: Matt Benson >Priority: Minor > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-131) test-modules should publish source jars
test-modules should publish source jars --- Key: EXTVAL-131 URL: https://issues.apache.org/jira/browse/EXTVAL-131 Project: MyFaces Extensions Validator Issue Type: Improvement Reporter: Matt Benson Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-132) DefaultValidationParameterFactory call to NullValueAwareConcurrentHashMap is considered ambiguous by Eclipse JDT compiler
DefaultValidationParameterFactory call to NullValueAwareConcurrentHashMap is considered ambiguous by Eclipse JDT compiler - Key: EXTVAL-132 URL: https://issues.apache.org/jira/browse/EXTVAL-132 Project: MyFaces Extensions Validator Issue Type: Improvement Reporter: Matt Benson Attachments: EXTVAL-132.patch.txt NVACHM provides (V) and (Class) constructors. When type parameters of the constructed map are and the constructor argument is a Class object the call is determined ambiguous as the argument is both a V and a Class. The provided patch satisfies the Eclipse compiler and works for both trunk and the -20 branch (it is assumed that it will work in the -11 branch as well). Don't shut out an entire IDE. ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EXTVAL-132) DefaultValidationParameterFactory call to NullValueAwareConcurrentHashMap is considered ambiguous by Eclipse JDT compiler
[ https://issues.apache.org/jira/browse/EXTVAL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated EXTVAL-132: --- Status: Patch Available (was: Open) > DefaultValidationParameterFactory call to NullValueAwareConcurrentHashMap is > considered ambiguous by Eclipse JDT compiler > - > > Key: EXTVAL-132 > URL: https://issues.apache.org/jira/browse/EXTVAL-132 > Project: MyFaces Extensions Validator > Issue Type: Improvement > Reporter: Matt Benson > Attachments: EXTVAL-132.patch.txt > > > NVACHM provides (V) and (Class) constructors. When type parameters of the > constructed map are and the constructor argument is a Class > object the call is determined ambiguous as the argument is both a V and a > Class. The provided patch satisfies the Eclipse compiler and works for > both trunk and the -20 branch (it is assumed that it will work in the -11 > branch as well). Don't shut out an entire IDE. ;) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACESTEST-50) myfaces-test20 TestPerClassLoaderRunner non-functional
myfaces-test20 TestPerClassLoaderRunner non-functional -- Key: MYFACESTEST-50 URL: https://issues.apache.org/jira/browse/MYFACESTEST-50 Project: MyFaces Test Issue Type: Bug Components: Build Procedure Reporter: Matt Benson Priority: Blocker the myfaces-test20 build fails to include excluded.properties from myfaces-test12, thus the TestClassLoader cannot find a large number of classes, e.g. java.lang.Object. For a high-profile example, this bug is the primary reason myfaces-extval cannot run its various test-modules against myfaces-test20. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-50) myfaces-test20 TestPerClassLoaderRunner non-functional
[ https://issues.apache.org/jira/browse/MYFACESTEST-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACESTEST-50: --- Status: Patch Available (was: Open) > myfaces-test20 TestPerClassLoaderRunner non-functional > -- > > Key: MYFACESTEST-50 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-50 > Project: MyFaces Test > Issue Type: Bug > Components: Build Procedure > Reporter: Matt Benson >Priority: Blocker > > the myfaces-test20 build fails to include excluded.properties from > myfaces-test12, thus the TestClassLoader cannot find a large number of > classes, e.g. java.lang.Object. For a high-profile example, this bug is the > primary reason myfaces-extval cannot run its various test-modules against > myfaces-test20. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup --- Key: EXTVAL-133 URL: https://issues.apache.org/jira/browse/EXTVAL-133 Project: MyFaces Extensions Validator Issue Type: Test Affects Versions: 2.0.5 Reporter: Matt Benson these tests work in trunk, but when running them against https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, they fail because the DefaultELHelper requests the ProjectStage so that it is cached before the testcase has the chance to add the "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to test successfully against trunk _and_ works for JSF 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
[ https://issues.apache.org/jira/browse/EXTVAL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated EXTVAL-133: --- Status: Patch Available (was: Open) > tests in > test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage > should customize servletContext as part of setup > --- > > Key: EXTVAL-133 > URL: https://issues.apache.org/jira/browse/EXTVAL-133 > Project: MyFaces Extensions Validator > Issue Type: Test >Affects Versions: 2.0.5 >Reporter: Matt Benson > > these tests work in trunk, but when running them against > https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, > they fail because the DefaultELHelper requests the ProjectStage so that it > is cached before the testcase has the chance to add the > "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to > test successfully against trunk _and_ works for JSF 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACESTEST-51) MockValueExpression should use the ELResolver provided by the ELContext instance passed to its methods
MockValueExpression should use the ELResolver provided by the ELContext instance passed to its methods -- Key: MYFACESTEST-51 URL: https://issues.apache.org/jira/browse/MYFACESTEST-51 Project: MyFaces Test Issue Type: Bug Components: Mock Objects Reporter: Matt Benson Attachments: MYFACESTEST-51.patch.txt For code that uses custom ELContext instances (e.g. myfaces-extval) the MockValueExpression behaves wrongly by directly fetching the ELResolver from the active FacesContext; this can be deferred to MockELContext for "normal" situations, and still function correctly for extraordinary situations such as described. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-51) MockValueExpression should use the ELResolver provided by the ELContext instance passed to its methods
[ https://issues.apache.org/jira/browse/MYFACESTEST-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACESTEST-51: --- Status: Patch Available (was: Open) > MockValueExpression should use the ELResolver provided by the ELContext > instance passed to its methods > -- > > Key: MYFACESTEST-51 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-51 > Project: MyFaces Test > Issue Type: Bug > Components: Mock Objects > Reporter: Matt Benson > Attachments: MYFACESTEST-51.patch.txt > > > For code that uses custom ELContext instances (e.g. myfaces-extval) the > MockValueExpression behaves wrongly by directly fetching the ELResolver from > the active FacesContext; this can be deferred to MockELContext for "normal" > situations, and still function correctly for extraordinary situations such as > described. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACESTEST-52) ValueExpression mocks cannot return types for null references
ValueExpression mocks cannot return types for null references - Key: MYFACESTEST-52 URL: https://issues.apache.org/jira/browse/MYFACESTEST-52 Project: MyFaces Test Issue Type: Improvement Components: Mock Objects Reporter: Matt Benson For example, MyFaces cannot deduce the proper converter for a given UIComponent if the target of its 'value' binding is null. Delegating to ELResolver.getType() fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-52) ValueExpression mocks cannot return types for null references
[ https://issues.apache.org/jira/browse/MYFACESTEST-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACESTEST-52: --- Status: Patch Available (was: Open) > ValueExpression mocks cannot return types for null references > - > > Key: MYFACESTEST-52 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-52 > Project: MyFaces Test > Issue Type: Improvement > Components: Mock Objects > Reporter: Matt Benson > > For example, MyFaces cannot deduce the proper converter for a given > UIComponent if the target of its 'value' binding is null. Delegating to > ELResolver.getType() fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACESTEST-52) ValueExpression mocks cannot return types for null references
[ https://issues.apache.org/jira/browse/MYFACESTEST-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036917#comment-13036917 ] Matt Benson edited comment on MYFACESTEST-52 at 5/20/11 4:39 PM: - (includes changes from MYFACESTEST-51.patch.txt) was (Author: mbenson): (includes changes from MYFACES-51.patch.txt) > ValueExpression mocks cannot return types for null references > - > > Key: MYFACESTEST-52 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-52 > Project: MyFaces Test > Issue Type: Improvement > Components: Mock Objects > Reporter: Matt Benson > Attachments: MYFACESTEST-52.patch.txt > > > For example, MyFaces cannot deduce the proper converter for a given > UIComponent if the target of its 'value' binding is null. Delegating to > ELResolver.getType() fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACESTEST-52) ValueExpression mocks cannot return types for null references
[ https://issues.apache.org/jira/browse/MYFACESTEST-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036917#comment-13036917 ] Matt Benson edited comment on MYFACESTEST-52 at 5/20/11 4:40 PM: - (includes changes from MYFACESTEST-51 patch) was (Author: mbenson): (includes changes from MYFACESTEST-51.patch.txt) > ValueExpression mocks cannot return types for null references > - > > Key: MYFACESTEST-52 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-52 > Project: MyFaces Test > Issue Type: Improvement > Components: Mock Objects > Reporter: Matt Benson > Attachments: MYFACESTEST-52.patch.txt > > > For example, MyFaces cannot deduce the proper converter for a given > UIComponent if the target of its 'value' binding is null. Delegating to > ELResolver.getType() fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
[ https://issues.apache.org/jira/browse/EXTVAL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037033#comment-13037033 ] Matt Benson edited comment on EXTVAL-133 at 5/20/11 7:49 PM: - MYFACESTEST-52 is a prerequisite to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 _without_ ExtValMockApplication was (Author: mbenson): This and related issues are prerequisites to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 > tests in > test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage > should customize servletContext as part of setup > --- > > Key: EXTVAL-133 > URL: https://issues.apache.org/jira/browse/EXTVAL-133 > Project: MyFaces Extensions Validator > Issue Type: Test >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Rudy De Busscher > Attachments: EXTVAL-133.patch.txt > > > these tests work in trunk, but when running them against > https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, > they fail because the DefaultELHelper requests the ProjectStage so that it > is cached before the testcase has the chance to add the > "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to > test successfully against trunk _and_ (with the minor tweak of a custom > ProjectStageResolver for the CustomProjectStageTestCase) works for JSF 2.0 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
[ https://issues.apache.org/jira/browse/EXTVAL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037033#comment-13037033 ] Matt Benson edited comment on EXTVAL-133 at 5/20/11 7:48 PM: - This and related issues are prerequisites to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 was (Author: mbenson): prerequisite to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 > tests in > test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage > should customize servletContext as part of setup > --- > > Key: EXTVAL-133 > URL: https://issues.apache.org/jira/browse/EXTVAL-133 > Project: MyFaces Extensions Validator > Issue Type: Test >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Rudy De Busscher > Attachments: EXTVAL-133.patch.txt > > > these tests work in trunk, but when running them against > https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, > they fail because the DefaultELHelper requests the ProjectStage so that it > is cached before the testcase has the chance to add the > "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to > test successfully against trunk _and_ (with the minor tweak of a custom > ProjectStageResolver for the CustomProjectStageTestCase) works for JSF 2.0 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
[ https://issues.apache.org/jira/browse/EXTVAL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037035#comment-13037035 ] Matt Benson edited comment on EXTVAL-133 at 5/20/11 7:50 PM: - MYFACESTEST-50 is a prerequisite to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 was (Author: mbenson): MYFACESTEST-52 is a prerequisite to successful testing of https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0 > tests in > test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage > should customize servletContext as part of setup > --- > > Key: EXTVAL-133 > URL: https://issues.apache.org/jira/browse/EXTVAL-133 > Project: MyFaces Extensions Validator > Issue Type: Test >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Rudy De Busscher > Attachments: EXTVAL-133.patch.txt > > > these tests work in trunk, but when running them against > https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, > they fail because the DefaultELHelper requests the ProjectStage so that it > is cached before the testcase has the chance to add the > "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to > test successfully against trunk _and_ (with the minor tweak of a custom > ProjectStageResolver for the CustomProjectStageTestCase) works for JSF 2.0 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3153) s/ServiceLoaderFinder/ServiceProviderFinder/g in ServiceProviderFinderFactory javadoc
s/ServiceLoaderFinder/ServiceProviderFinder/g in ServiceProviderFinderFactory javadoc - Key: MYFACES-3153 URL: https://issues.apache.org/jira/browse/MYFACES-3153 Project: MyFaces Core Issue Type: Improvement Components: SPI Affects Versions: 2.0.5 Reporter: Matt Benson Priority: Trivial -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3153) s/ServiceLoaderFinder/ServiceProviderFinder/g in ServiceProviderFinderFactory javadoc
[ https://issues.apache.org/jira/browse/MYFACES-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3153: - Status: Patch Available (was: Open) > s/ServiceLoaderFinder/ServiceProviderFinder/g in ServiceProviderFinderFactory > javadoc > - > > Key: MYFACES-3153 > URL: https://issues.apache.org/jira/browse/MYFACES-3153 > Project: MyFaces Core > Issue Type: Improvement > Components: SPI >Affects Versions: 2.0.5 >Reporter: Matt Benson >Priority: Trivial > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACESTEST-53) MockApplication12 elResolver cannot interpret EL reserved words
MockApplication12 elResolver cannot interpret EL reserved words --- Key: MYFACESTEST-53 URL: https://issues.apache.org/jira/browse/MYFACESTEST-53 Project: MyFaces Test Issue Type: Bug Reporter: Matt Benson Attachments: MYFACESTEST-53.patch.txt This bug necessitates another workaround for extval. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-53) MockApplication12 elResolver cannot interpret EL reserved words
[ https://issues.apache.org/jira/browse/MYFACESTEST-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACESTEST-53: --- Status: Patch Available (was: Open) > MockApplication12 elResolver cannot interpret EL reserved words > --- > > Key: MYFACESTEST-53 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-53 > Project: MyFaces Test > Issue Type: Bug > Reporter: Matt Benson > Attachments: MYFACESTEST-53.patch.txt > > > This bug necessitates another workaround for extval. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTVAL-133) tests in test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage should customize servletContext as part of setup
[ https://issues.apache.org/jira/browse/EXTVAL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040261#comment-13040261 ] Matt Benson commented on EXTVAL-133: Yes, I actually intended this issue as more a stepping-stone to a full-fledged "test extval on the 2.0 branch" issue, wherein I could submit the tweak as a patch against trunk. However, I can also submit the 2.0 version of the patch. > tests in > test-modules/core-tests/src/test/java/org/apache/myfaces/extensions/validator/test/core/stage > should customize servletContext as part of setup > --- > > Key: EXTVAL-133 > URL: https://issues.apache.org/jira/browse/EXTVAL-133 > Project: MyFaces Extensions Validator > Issue Type: Test >Affects Versions: 2.0.5 >Reporter: Matt Benson >Assignee: Rudy De Busscher > Attachments: EXTVAL-133.patch.txt > > > these tests work in trunk, but when running them against > https://svn.apache.org/repos/asf/myfaces/extensions/validator/branches/branch_for_jsf_2_0, > they fail because the DefaultELHelper requests the ProjectStage so that it > is cached before the testcase has the chance to add the > "javax.faces.PROJECT_STAGE" init parameter. The attached patch continues to > test successfully against trunk _and_ (with the minor tweak of a custom > ProjectStageResolver for the CustomProjectStageTestCase) works for JSF 2.0 . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACESTEST-52) ValueExpression mocks cannot return types for null references
[ https://issues.apache.org/jira/browse/MYFACESTEST-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040267#comment-13040267 ] Matt Benson commented on MYFACESTEST-52: Easier, yes. Fully correct, no. Once again, this touches on the concept of "when does the mock framework become a full-fledged implementation of unified EL?" but I don't think we've reached that point yet. With both of us fully aware that I am working against extval's tests, when I return expectedType from MockValueExpression.getValue() I still can't pass all the tests while using the built-in MockApplicationFactory. > ValueExpression mocks cannot return types for null references > - > > Key: MYFACESTEST-52 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-52 > Project: MyFaces Test > Issue Type: Improvement > Components: Mock Objects >Reporter: Matt Benson > Attachments: MYFACESTEST-52.patch.txt > > > For example, MyFaces cannot deduce the proper converter for a given > UIComponent if the target of its 'value' binding is null. Delegating to > ELResolver.getType() fixes this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACESTEST-51) MockValueExpression should use the ELResolver provided by the ELContext instance passed to its methods
[
https://issues.apache.org/jira/browse/MYFACESTEST-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040284#comment-13040284
]
Matt Benson commented on MYFACESTEST-51:
>From the EL spec:
{quote}
The ELResolver in the ELContext is used to resolve the top-level variables and
to determine the behavior of the . and [] operators.
{quote}
> MockValueExpression should use the ELResolver provided by the ELContext
> instance passed to its methods
> --
>
> Key: MYFACESTEST-51
> URL: https://issues.apache.org/jira/browse/MYFACESTEST-51
> Project: MyFaces Test
> Issue Type: Bug
> Components: Mock Objects
>Reporter: Matt Benson
> Attachments: MYFACESTEST-51.patch.txt
>
>
> For code that uses custom ELContext instances (e.g. myfaces-extval) the
> MockValueExpression behaves wrongly by directly fetching the ELResolver from
> the active FacesContext; this can be deferred to MockELContext for "normal"
> situations, and still function correctly for extraordinary situations such as
> described.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACESTEST-51) MockValueExpression should use the ELResolver provided by the ELContext instance passed to its methods
[
https://issues.apache.org/jira/browse/MYFACESTEST-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040284#comment-13040284
]
Matt Benson edited comment on MYFACESTEST-51 at 5/27/11 3:22 PM:
-
>From the EL spec:
The ELResolver in the ELContext is used to resolve the top-level variables
and to determine the behavior of the . and [] operators.
was (Author: mbenson):
From the EL spec:
{quote}
The ELResolver in the ELContext is used to resolve the top-level variables and
to determine the behavior of the . and [] operators.
{quote}
> MockValueExpression should use the ELResolver provided by the ELContext
> instance passed to its methods
> --
>
> Key: MYFACESTEST-51
> URL: https://issues.apache.org/jira/browse/MYFACESTEST-51
> Project: MyFaces Test
> Issue Type: Bug
> Components: Mock Objects
>Reporter: Matt Benson
> Attachments: MYFACESTEST-51.patch.txt
>
>
> For code that uses custom ELContext instances (e.g. myfaces-extval) the
> MockValueExpression behaves wrongly by directly fetching the ELResolver from
> the active FacesContext; this can be deferred to MockELContext for "normal"
> situations, and still function correctly for extraordinary situations such as
> described.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACESTEST-55) MockValueExpression cannot handle list/array indices
MockValueExpression cannot handle list/array indices Key: MYFACESTEST-55 URL: https://issues.apache.org/jira/browse/MYFACESTEST-55 Project: MyFaces Test Issue Type: Bug Components: Mock Objects Reporter: Matt Benson myfaces-extval trunk tests successfully with myfaces-test12 + this patch myfaces-core trunk tests successfully with myfaces-test20 + this patch myfaces-extcdi trunk tests successfully with myfaces-test12 + this patch myfaces-extval JSF2.0 branch tests successfully with myfaces-test20 + this patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-55) MockValueExpression cannot handle list/array indices
[ https://issues.apache.org/jira/browse/MYFACESTEST-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACESTEST-55: --- Status: Patch Available (was: Open) > MockValueExpression cannot handle list/array indices > > > Key: MYFACESTEST-55 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-55 > Project: MyFaces Test > Issue Type: Bug > Components: Mock Objects > Reporter: Matt Benson > > myfaces-extval trunk tests successfully with myfaces-test12 + this patch > myfaces-core trunk tests successfully with myfaces-test20 + this patch > myfaces-extcdi trunk tests successfully with myfaces-test12 + this patch > myfaces-extval JSF2.0 branch tests successfully with myfaces-test20 + this > patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACESTEST-55) MockValueExpression cannot handle list/array indices
[ https://issues.apache.org/jira/browse/MYFACESTEST-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042750#comment-13042750 ] Matt Benson commented on MYFACESTEST-55: BTW, patch attached does also contain test code. > MockValueExpression cannot handle list/array indices > > > Key: MYFACESTEST-55 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-55 > Project: MyFaces Test > Issue Type: Bug > Components: Mock Objects > Reporter: Matt Benson > Attachments: MYFACESTEST-55.patch.txt > > > myfaces-extval trunk tests successfully with myfaces-test12 + this patch > myfaces-core trunk tests successfully with myfaces-test20 + this patch > myfaces-extcdi trunk tests successfully with myfaces-test12 + this patch > myfaces-extval JSF2.0 branch tests successfully with myfaces-test20 + this > patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACESTEST-55) MockValueExpression cannot handle list/array indices
[ https://issues.apache.org/jira/browse/MYFACESTEST-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043352#comment-13043352 ] Matt Benson commented on MYFACESTEST-55: Thanks Rudy! > MockValueExpression cannot handle list/array indices > > > Key: MYFACESTEST-55 > URL: https://issues.apache.org/jira/browse/MYFACESTEST-55 > Project: MyFaces Test > Issue Type: Bug > Components: Mock Objects > Reporter: Matt Benson >Assignee: Rudy De Busscher > Fix For: 1.0.4-SNAPSHOT > > Attachments: MYFACESTEST-55.patch.txt > > > myfaces-extval trunk tests successfully with myfaces-test12 + this patch > myfaces-core trunk tests successfully with myfaces-test20 + this patch > myfaces-extcdi trunk tests successfully with myfaces-test12 + this patch > myfaces-extval JSF2.0 branch tests successfully with myfaces-test20 + this > patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3172) UIComponentBase.isValid(id) check could mention the offending value in exceptions
UIComponentBase.isValid(id) check could mention the offending value in exceptions - Key: MYFACES-3172 URL: https://issues.apache.org/jira/browse/MYFACES-3172 Project: MyFaces Core Issue Type: Improvement Reporter: Matt Benson When an illegal character is encountered an IllegalArgumentException is thrown which explains the nature of the violation as well as the unexpected character. It would be much easier to address the cause of such an exception, however, if the entire illegal id were presented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3184) h:selectOneRadio cannot support f:ajax if @id not set
h:selectOneRadio cannot support f:ajax if @id not set - Key: MYFACES-3184 URL: https://issues.apache.org/jira/browse/MYFACES-3184 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.1 Reporter: Matt Benson if the id is set, it is written to the containing table and everything works fine. Otherwise, the client-side DOM has no element with the id of the selectOneRadio component and the full effects of the ajax call (e.g. listener method invocation) are never carried out. Also fails on Mojarra, FYI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3184) h:selectOneRadio cannot support f:ajax if @id not set
[ https://issues.apache.org/jira/browse/MYFACES-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053334#comment-13053334 ] Matt Benson commented on MYFACES-3184: -- Thank you for the 1hr turnaround! :D > h:selectOneRadio cannot support f:ajax if @id not set > - > > Key: MYFACES-3184 > URL: https://issues.apache.org/jira/browse/MYFACES-3184 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.1 > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.8, 2.1.2 > > Attachments: mf3184.tar.gz > > > if the id is set, it is written to the containing table and everything works > fine. Otherwise, the client-side DOM has no element with the id of the > selectOneRadio component and the full effects of the ajax call (e.g. listener > method invocation) are never carried out. Works on Mojarra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3184) h:selectOneRadio cannot support f:ajax if @id not set
[ https://issues.apache.org/jira/browse/MYFACES-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053335#comment-13053335 ] Matt Benson commented on MYFACES-3184: -- Except... is 2.1.2 the right target version, since the attempted 2.1.1 release was vetoed? > h:selectOneRadio cannot support f:ajax if @id not set > - > > Key: MYFACES-3184 > URL: https://issues.apache.org/jira/browse/MYFACES-3184 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.1 > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.8, 2.1.2 > > Attachments: mf3184.tar.gz > > > if the id is set, it is written to the containing table and everything works > fine. Otherwise, the client-side DOM has no element with the id of the > selectOneRadio component and the full effects of the ajax call (e.g. listener > method invocation) are never carried out. Works on Mojarra. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3186) ui:repeat can lose dynamically added grandchild components
ui:repeat can lose dynamically added grandchild components
--
Key: MYFACES-3186
URL: https://issues.apache.org/jira/browse/MYFACES-3186
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.1, 2.1.2-SNAPSHOT
Reporter: Matt Benson
Somewhat complicated to explain... myfaces-extval, for example, can make
changes to components by intercepting {{Renderer.encodeBegin()}. My experience
is this:
I have a ui:repeat, in which I nest an h:selectOneMenu. If I add its child
elements using a renderer interceptor approach like that of extval, these are
lost after the view is rendered, so that the form submit fails due to the
h:selectOneMenu having no selectItems available. Other h:selectOneMenu
components in the tree work properly when I add children in the same way, thus
I believe that ui:repeat is where the problem arises. I am attaching a project
demonstrating the situation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3186) ui:repeat can lose dynamically added grandchild components
[ https://issues.apache.org/jira/browse/MYFACES-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054653#comment-13054653 ] Matt Benson commented on MYFACES-3186: -- btw, works on Mojarra > ui:repeat can lose dynamically added grandchild components > -- > > Key: MYFACES-3186 > URL: https://issues.apache.org/jira/browse/MYFACES-3186 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.1, 2.1.2-SNAPSHOT >Reporter: Matt Benson > Attachments: MF-3186.tar.gz > > > Somewhat complicated to explain... myfaces-extval, for example, can make > changes to components by intercepting Renderer.encodeBegin(). My experience > is this: > I have a ui:repeat, in which I nest an h:selectOneMenu. If I add its child > elements using a renderer interceptor approach like that of extval, these are > lost after the view is rendered, so that the form submit fails due to the > h:selectOneMenu having no selectItems available. Other h:selectOneMenu > components in the tree work properly when I add children in the same way, > thus I believe that ui:repeat is where the problem arises. I am attaching a > project demonstrating the situation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3186) ui:repeat can lose dynamically added grandchild components
[ https://issues.apache.org/jira/browse/MYFACES-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1301#comment-1301 ] Matt Benson commented on MYFACES-3186: -- Thanks as always for your prompt attention, Leo. Just tried the snapshot build and it looks like I'm all set. :) > ui:repeat can lose dynamically added grandchild components > -- > > Key: MYFACES-3186 > URL: https://issues.apache.org/jira/browse/MYFACES-3186 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.1.1, 2.1.2-SNAPSHOT >Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.8, 2.1.2 > > Attachments: MF-3186.tar.gz > > > Somewhat complicated to explain... myfaces-extval, for example, can make > changes to components by intercepting Renderer.encodeBegin(). My experience > is this: > I have a ui:repeat, in which I nest an h:selectOneMenu. If I add its child > elements using a renderer interceptor approach like that of extval, these are > lost after the view is rendered, so that the form submit fails due to the > h:selectOneMenu having no selectItems available. Other h:selectOneMenu > components in the tree work properly when I add children in the same way, > thus I believe that ui:repeat is where the problem arises. I am attaching a > project demonstrating the situation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3194) trivial improvements to procedural commentary in FacesServlet.service()
[ https://issues.apache.org/jira/browse/MYFACES-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3194: - Status: Patch Available (was: Open) > trivial improvements to procedural commentary in FacesServlet.service() > --- > > Key: MYFACES-3194 > URL: https://issues.apache.org/jira/browse/MYFACES-3194 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.2-SNAPSHOT > Reporter: Matt Benson >Priority: Trivial > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3194) trivial improvements to procedural commentary in FacesServlet.service()
trivial improvements to procedural commentary in FacesServlet.service() --- Key: MYFACES-3194 URL: https://issues.apache.org/jira/browse/MYFACES-3194 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.2-SNAPSHOT Reporter: Matt Benson Priority: Trivial -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
[ https://issues.apache.org/jira/browse/MYFACES-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057939#comment-13057939 ] Matt Benson commented on MYFACES-3200: -- Not sure what if anything richfaces is contributing to the mix here, but I'd like to note that I have seen this behavior for composite component attributes when PSS is disabled on a JSF app with only core components in use. I simply hadn't put together the sample yet to submit the issue myself. :) > All values of self-defined composite-component attributes disappear > unexpected. > --- > > Key: MYFACES-3200 > URL: https://issues.apache.org/jira/browse/MYFACES-3200 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.2-SNAPSHOT > Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 > (30.06.2011) >Reporter: Rene O > Attachments: jsf2testcase.war > > > A testcase to reproduce this issue is attached. > Steps to reproduce this issue: > 1. http://localhost:8080/jsf2testcase/components.jsf > 2. you can see the value of one of the attributes of the self-defined > composite component at 'Panel1' > 2. click 'Panel2' > 3. click 'Panel1' > 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' > after that, the value is there again) > Note: > This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) > With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with > myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3200) All values of self-defined composite-component attributes disappear unexpected.
[ https://issues.apache.org/jira/browse/MYFACES-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058090#comment-13058090 ] Matt Benson commented on MYFACES-3200: -- Great! I was also going to say that yes, it has to do with ajax updates. ;) > All values of self-defined composite-component attributes disappear > unexpected. > --- > > Key: MYFACES-3200 > URL: https://issues.apache.org/jira/browse/MYFACES-3200 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.1.2-SNAPSHOT > Environment: Java 6, Tomcat 6, latest SNAPSHOT of myfaces-2.1.2 > (30.06.2011) >Reporter: Rene O > Attachments: jsf2testcase.war, jsf2testcasewithoutrichfaces.war > > > A testcase to reproduce this issue is attached. > Steps to reproduce this issue: > 1. http://localhost:8080/jsf2testcase/components.jsf > 2. you can see the value of one of the attributes of the self-defined > composite component at 'Panel1' > 2. click 'Panel2' > 3. click 'Panel1' > 4. value at 'Panel1' is not shown anymore. (if you refresh the page with 'F5' > after that, the value is there again) > Note: > This behaviour occurs with the latest myfaces-2.1.2-SNAPSHOT (30.06.2011) > With an older version of myfaces-2.1.2-SNAPSHOT (22.06.2011) and with > myfaces-2.1.1 everything works as expected. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3220) reduce number of PhaseEvent instances created
[ https://issues.apache.org/jira/browse/MYFACES-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3220: - Status: Patch Available (was: Open) > reduce number of PhaseEvent instances created > - > > Key: MYFACES-3220 > URL: https://issues.apache.org/jira/browse/MYFACES-3220 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.1.2-SNAPSHOT > Reporter: Matt Benson >Priority: Minor > > PhaseListenerManager currently creates a new PhaseEvent instance per phaseId, > per listener, per before/after. The supplied patch reduces this to per > phaseId, per before/after, sharing instances of this immutable class among > listeners. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3220) reduce number of PhaseEvent instances created
reduce number of PhaseEvent instances created - Key: MYFACES-3220 URL: https://issues.apache.org/jira/browse/MYFACES-3220 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.2-SNAPSHOT Reporter: Matt Benson Priority: Minor PhaseListenerManager currently creates a new PhaseEvent instance per phaseId, per listener, per before/after. The supplied patch reduces this to per phaseId, per before/after, sharing instances of this immutable class among listeners. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-2552) TagValueExpression.getType() returns null if the property in the managed bean is null and the expression points to a facelets composite component attribute
[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071894#comment-13071894
]
Matt Benson edited comment on MYFACES-2552 at 7/27/11 6:09 PM:
---
For future reference, this issue can be worked around in any JSF 2+ environment
by simply adding a custom ELResolver with this method:
@Override
public Class getType(ELContext context, Object base, Object property) {
if (base instanceof CompositeComponentExpressionHolder && property
instanceof String) {
ValueExpression expr = ((CompositeComponentExpressionHolder)
base).getExpression((String) property);
if (expr != null) {
return expr.getType(context);
}
}
return null;
}
Remaining methods should return {{null}}/{{false}} i.e. do nothing.
was (Author: mbenson):
For future reference, this issue can be worked around in any JSF 2+
environment by simply adding a custom ELResolver with this method:
{noformat}
@Override
public Class getType(ELContext context, Object base, Object property) {
if (base instanceof CompositeComponentExpressionHolder && property
instanceof String) {
ValueExpression expr = ((CompositeComponentExpressionHolder)
base).getExpression((String) property);
if (expr != null) {
return expr.getType(context);
}
}
return null;
}
{noformat}
Remaining methods should return {{null}}/{{false}} i.e. do nothing.
> TagValueExpression.getType() returns null if the property in the managed bean
> is null and the expression points to a facelets composite component attribute
> ---
>
> Key: MYFACES-2552
> URL: https://issues.apache.org/jira/browse/MYFACES-2552
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.1.0
>Reporter: Jakob Korherr
>Assignee: Jakob Korherr
> Attachments: MYFACES-2552-spec-proposal.patch
>
>
> if you have a facelets composite component with an attribute "test" that
> points to a property in a managed bean (e.g. #{myBean.property}) which is
> currently null and you refer to that attribute in the implementation via
> #{cc.attrs.test} you can get the current value (null) or set a new value but
> you cannot get the type of the property (e.g. String[]). However if the
> property in the managed bean is non-null you can get the type.
> For example:
>
>
>
>
>
>
>
>
> --> calling #{cc.attrs.test}.getType() will fail if #{cc.attrs.test} resolves
> to null, but will work if #{cc.attrs.test} resolves to some valid value.
> This currently results in a NullPointerException in
> _SharedRendererUtils.getConvertedUISelectManyValue().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-2552) TagValueExpression.getType() returns null if the property in the managed bean is null and the expression points to a facelets composite component attribute
[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071894#comment-13071894
]
Matt Benson commented on MYFACES-2552:
--
For future reference, this issue can be worked around in any JSF 2+ environment
by simply adding a custom ELResolver with this method:
{noformat}
@Override
public Class getType(ELContext context, Object base, Object property) {
if (base instanceof CompositeComponentExpressionHolder && property
instanceof String) {
ValueExpression expr = ((CompositeComponentExpressionHolder)
base).getExpression((String) property);
if (expr != null) {
return expr.getType(context);
}
}
return null;
}
{noformat}
Remaining methods should return {{null}}/{{false}} i.e. do nothing.
> TagValueExpression.getType() returns null if the property in the managed bean
> is null and the expression points to a facelets composite component attribute
> ---
>
> Key: MYFACES-2552
> URL: https://issues.apache.org/jira/browse/MYFACES-2552
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.1.0
>Reporter: Jakob Korherr
>Assignee: Jakob Korherr
> Attachments: MYFACES-2552-spec-proposal.patch
>
>
> if you have a facelets composite component with an attribute "test" that
> points to a property in a managed bean (e.g. #{myBean.property}) which is
> currently null and you refer to that attribute in the implementation via
> #{cc.attrs.test} you can get the current value (null) or set a new value but
> you cannot get the type of the property (e.g. String[]). However if the
> property in the managed bean is non-null you can get the type.
> For example:
>
>
>
>
>
>
>
>
> --> calling #{cc.attrs.test}.getType() will fail if #{cc.attrs.test} resolves
> to null, but will work if #{cc.attrs.test} resolves to some valid value.
> This currently results in a NullPointerException in
> _SharedRendererUtils.getConvertedUISelectManyValue().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-2552) TagValueExpression.getType() returns null if the property in the managed bean is null and the expression points to a facelets composite component attribute
[
https://issues.apache.org/jira/browse/MYFACES-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071894#comment-13071894
]
Matt Benson edited comment on MYFACES-2552 at 7/27/11 6:12 PM:
---
For future reference, this issue can be worked around in any JSF 2+ environment
by simply adding a custom ELResolver with this method:
@Override
public Class getType(ELContext context, Object base, Object property) {
if (base instanceof CompositeComponentExpressionHolder && property
instanceof String) {
ValueExpression expr = ((CompositeComponentExpressionHolder)
base).getExpression((String) property);
if (expr != null) {
return expr.getType(context);
}
}
return null;
}
Remaining methods should return null/false i.e. do nothing.
was (Author: mbenson):
For future reference, this issue can be worked around in any JSF 2+
environment by simply adding a custom ELResolver with this method:
@Override
public Class getType(ELContext context, Object base, Object property) {
if (base instanceof CompositeComponentExpressionHolder && property
instanceof String) {
ValueExpression expr = ((CompositeComponentExpressionHolder)
base).getExpression((String) property);
if (expr != null) {
return expr.getType(context);
}
}
return null;
}
Remaining methods should return {{null}}/{{false}} i.e. do nothing.
> TagValueExpression.getType() returns null if the property in the managed bean
> is null and the expression points to a facelets composite component attribute
> ---
>
> Key: MYFACES-2552
> URL: https://issues.apache.org/jira/browse/MYFACES-2552
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.1.0
>Reporter: Jakob Korherr
>Assignee: Jakob Korherr
> Attachments: MYFACES-2552-spec-proposal.patch
>
>
> if you have a facelets composite component with an attribute "test" that
> points to a property in a managed bean (e.g. #{myBean.property}) which is
> currently null and you refer to that attribute in the implementation via
> #{cc.attrs.test} you can get the current value (null) or set a new value but
> you cannot get the type of the property (e.g. String[]). However if the
> property in the managed bean is non-null you can get the type.
> For example:
>
>
>
>
>
>
>
>
> --> calling #{cc.attrs.test}.getType() will fail if #{cc.attrs.test} resolves
> to null, but will work if #{cc.attrs.test} resolves to some valid value.
> This currently results in a NullPointerException in
> _SharedRendererUtils.getConvertedUISelectManyValue().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3251) composite component attributes with @method-signature declared should carry through as MethodExpressions, but do not
composite component attributes with @method-signature declared should carry through as MethodExpressions, but do not Key: MYFACES-3251 URL: https://issues.apache.org/jira/browse/MYFACES-3251 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2-SNAPSHOT Reporter: Matt Benson for this reason e.g. a cc cannot propagate an action attribute to an inner h:commandButton. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3256) CommonPropertyUtils assumes all its managed HTML attributes hold string values
CommonPropertyUtils assumes all its managed HTML attributes hold string values
--
Key: MYFACES-3256
URL: https://issues.apache.org/jira/browse/MYFACES-3256
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.8-SNAPSHOT, 2.1.2-SNAPSHOT
Reporter: Matt Benson
Priority: Blocker
I encountered the ClassCastException due to Integer vs. String on {{h:input
@maxlength}}, which is defined at
http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/h/inputText.html
as {{(must evaluate to int)}}. I would presume the same for {{@size}}
({{int}}) and {{@readonly}} ({{boolean}}). Perhaps naively, it would seem that
simply removing the {{String}} cast and using {{Object}} in
{{CommonPropertyUtils#renderHtmlStringAttribute()}} (potentially renaming this
method in the process) would solve the issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3256) CommonPropertyUtils assumes all its managed HTML attributes hold string values
[ https://issues.apache.org/jira/browse/MYFACES-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078302#comment-13078302 ] Matt Benson commented on MYFACES-3256: -- Thanks for the quick turnaround, Leo! > CommonPropertyUtils assumes all its managed HTML attributes hold string values > -- > > Key: MYFACES-3256 > URL: https://issues.apache.org/jira/browse/MYFACES-3256 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.8-SNAPSHOT, 2.1.2-SNAPSHOT > Reporter: Matt Benson >Assignee: Leonardo Uribe >Priority: Blocker > Fix For: 2.0.8, 2.1.2 > > > I encountered the ClassCastException due to Integer vs. String on h:input > @maxlength, which is defined at > http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/h/inputText.html > as (must evaluate to int). I would presume the same for @size (int) and > @readonly (boolean). Perhaps naively, it would seem that simply removing the > String cast and using Object in > CommonPropertyUtils#renderHtmlStringAttribute() (potentially renaming this > method in the process) would solve the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3251) composite component attributes with @method-signature declared should carry through as MethodExpressions, but do not
[
https://issues.apache.org/jira/browse/MYFACES-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078406#comment-13078406
]
Matt Benson commented on MYFACES-3251:
--
Thanks, Leo... actually as it turned out in this case I needed to pull the
current value of the attribute for inspection, which made the @targets setup
more suited to my needs anyway: pulling
getActionExpression().getExpressionString() returned "#{cc.attrs.action}", on
which I'd have had to do a lot of mining to do the inspection I am doing. ;)
> composite component attributes with @method-signature declared should carry
> through as MethodExpressions, but do not
>
>
> Key: MYFACES-3251
> URL: https://issues.apache.org/jira/browse/MYFACES-3251
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.2-SNAPSHOT
>Reporter: Matt Benson
>Assignee: Leonardo Uribe
> Fix For: 2.0.8, 2.1.2
>
> Attachments: MYFACES-3251.tar.gz
>
>
> for this reason e.g. a cc cannot propagate an action attribute to an inner
> h:commandButton.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode -- Key: MYFACES-3259 URL: https://issues.apache.org/jira/browse/MYFACES-3259 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson demo forthcoming; it would seem the FaceletCompositionContext would need to keep track of the delegate as well as the id of enclosing validators in order to be able to apply the xml attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3274) CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks compatibility with tmp el-resolvers
CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks compatibility with tmp el-resolvers -- Key: MYFACES-3274 URL: https://issues.apache.org/jira/browse/MYFACES-3274 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson ELContext should not be cached; if the first ELContext to access cc.attrs happens to be a third-party component such as ExtVal, this ELContext will continue to be used for this component, wrongly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3274) CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks compatibility with tmp el-resolvers
[ https://issues.apache.org/jira/browse/MYFACES-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated MYFACES-3274: - Status: Patch Available (was: Open) > CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks > compatibility with tmp el-resolvers > -- > > Key: MYFACES-3274 > URL: https://issues.apache.org/jira/browse/MYFACES-3274 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson > Attachments: MYFACES-3274.patch.txt > > > ELContext should not be cached; if the first ELContext to access cc.attrs > happens to be a third-party component such as ExtVal, this ELContext will > continue to be used for this component, wrongly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3274) CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks compatibility with tmp el-resolvers
[ https://issues.apache.org/jira/browse/MYFACES-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084284#comment-13084284 ] Matt Benson commented on MYFACES-3274: -- Thanks, Leo! > CompositeComponentELResolver.CompositeComponentAttributesMapWrapper breaks > compatibility with tmp el-resolvers > -- > > Key: MYFACES-3274 > URL: https://issues.apache.org/jira/browse/MYFACES-3274 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson >Assignee: Leonardo Uribe > Fix For: 2.0.8, 2.1.2 > > Attachments: MYFACES-3274.patch.txt > > > ELContext should not be cached; if the first ELContext to access cc.attrs > happens to be a third-party component such as ExtVal, this ELContext will > continue to be used for this component, wrongly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084423#comment-13084423 ] Matt Benson commented on MYFACES-3259: -- Thanks for the attention, Leo. I agree that this wasn't covered in the spec. I'll reread those sections and file an issue. > Custom Validator tag attributes are not configured when used with default tag > handler in wrapping mode > -- > > Key: MYFACES-3259 > URL: https://issues.apache.org/jira/browse/MYFACES-3259 > Project: MyFaces Core > Issue Type: Bug >Reporter: Matt Benson > Attachments: MYFACES-3259.tar.gz, MYFACES-3259.tar.gz > > > demo forthcoming; it would seem the FaceletCompositionContext would need to > keep track of the delegate as well as the id of enclosing validators in order > to be able to apply the xml attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085924#comment-13085924 ] Matt Benson commented on MYFACES-3259: -- Filed http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 . In the meantime, is there any reason MyFaces should not support this functionality on an implementation-specific basis? > Custom Validator tag attributes are not configured when used with default tag > handler in wrapping mode > -- > > Key: MYFACES-3259 > URL: https://issues.apache.org/jira/browse/MYFACES-3259 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson > Attachments: MYFACES-3259.tar.gz, MYFACES-3259.tar.gz > > > demo forthcoming; it would seem the FaceletCompositionContext would need to > keep track of the delegate as well as the id of enclosing validators in order > to be able to apply the xml attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085953#comment-13085953 ] Matt Benson commented on MYFACES-3259: -- How can I help? > Custom Validator tag attributes are not configured when used with default tag > handler in wrapping mode > -- > > Key: MYFACES-3259 > URL: https://issues.apache.org/jira/browse/MYFACES-3259 > Project: MyFaces Core > Issue Type: Bug > Reporter: Matt Benson > Attachments: MYFACES-3259.tar.gz, MYFACES-3259.tar.gz > > > demo forthcoming; it would seem the FaceletCompositionContext would need to > keep track of the delegate as well as the id of enclosing validators in order > to be able to apply the xml attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved MYFACES-3283.
--
Resolution: Invalid
In cases where you rely on the component stack in this manner you can query
this information in the context of a tree visit (I personally have gotten into
the habit of doing nearly everything in a tree visit for this reason).
> #{cc.attr} attributes fail when a child component is accessed outside of the
> composite component (i.e. in action listeners or other events)
> ---
>
> Key: MYFACES-3283
> URL: https://issues.apache.org/jira/browse/MYFACES-3283
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
> Environment: Mac OS 10.6, Tomcat 7
>Reporter: Kito D. Mann
> Attachments: myfaces_cc_issue.war
>
>
> If you reference a property of child component anywhere outside of the
> composite's context (i.e. in an action method, a component system event
> listener, etc.), the property will not be evaluated properly if the
> expression is a composite component attribute (i.e. "#{cc.attrs.property}").
> This is because the EL evaluation code can't find the parent composite
> component.
> For example, consider the composite component:
>
> http://www.w3.org/1999/xhtml";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:composite="http://java.sun.com/jsf/composite";>
>
>
>
>
>
>
>
>
>
> The calling page:
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";
> xmlns:ui="http://java.sun.com/jsf/facelets";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:f="http://java.sun.com/jsf/core";
> xmlns:ez="http://java.sun.com/jsf/composite/demo";>
>
>
>
>
> value="#{testBean.value}" />
>action="#{testBean.testCcAttribute}" />
>
>
>
> Here's testBean.testCcAttribute():
> public String testCcAttribute() {
> HtmlInputText input =
> (HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent("form:composite:input");
> UIComponent composite =
> FacesContext.getCurrentInstance().getViewRoot().findComponent("form:composite");
> String message = "Input control label attribute is: " +
> input.getLabel() + "; Composite label attribute is: " +
> composite.getAttributes().get("label");
> display(message);
> return null;
> }
> This action method generates the following message:
> Input control label attribute is: null; Composite label attribute is: Enter
> something:
> ---
> Full example WAR attached.
> Note this is the same as the following issue with Mojarra:
> http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086674#comment-13086674
]
Matt Benson commented on MYFACES-3283:
--
wrt the Mojarra-reported issue, to judge from its description I gauge it may be
slightly more complex and thus could be valid; however the simple case you
outline above does not, as best I can tell, qualify as a situation in which you
should expect the component stack to be in such a state as to resolve properly.
> #{cc.attr} attributes fail when a child component is accessed outside of the
> composite component (i.e. in action listeners or other events)
> ---
>
> Key: MYFACES-3283
> URL: https://issues.apache.org/jira/browse/MYFACES-3283
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
> Environment: Mac OS 10.6, Tomcat 7
>Reporter: Kito D. Mann
> Attachments: myfaces_cc_issue.war
>
>
> If you reference a property of child component anywhere outside of the
> composite's context (i.e. in an action method, a component system event
> listener, etc.), the property will not be evaluated properly if the
> expression is a composite component attribute (i.e. "#{cc.attrs.property}").
> This is because the EL evaluation code can't find the parent composite
> component.
> For example, consider the composite component:
>
> http://www.w3.org/1999/xhtml";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:composite="http://java.sun.com/jsf/composite";>
>
>
>
>
>
>
>
>
>
> The calling page:
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";
> xmlns:ui="http://java.sun.com/jsf/facelets";
> xmlns:h="http://java.sun.com/jsf/html";
> xmlns:f="http://java.sun.com/jsf/core";
> xmlns:ez="http://java.sun.com/jsf/composite/demo";>
>
>
>
>
> value="#{testBean.value}" />
>action="#{testBean.testCcAttribute}" />
>
>
>
> Here's testBean.testCcAttribute():
> public String testCcAttribute() {
> HtmlInputText input =
> (HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent("form:composite:input");
> UIComponent composite =
> FacesContext.getCurrentInstance().getViewRoot().findComponent("form:composite");
> String message = "Input control label attribute is: " +
> input.getLabel() + "; Composite label attribute is: " +
> composite.getAttributes().get("label");
> display(message);
> return null;
> }
> This action method generates the following message:
> Input control label attribute is: null; Composite label attribute is: Enter
> something:
> ---
> Full example WAR attached.
> Note this is the same as the following issue with Mojarra:
> http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
