Use 1.2 as current now
Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current now
+1 On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
RE: Use 1.2 as current now
Sounds like a good idea. One question however: Tomcat 6 requires JDK 5. Does this mean that the trunk will drop JDK 1.4 compatibility? Regards, Erik-Berndt -Oorspronkelijk bericht- Van: Martin Marinschek [mailto:[EMAIL PROTECTED] Verzonden: woensdag 18 april 2007 10:07 Aan: MyFaces Development Onderwerp: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: Use 1.2 as current now
Jetty is also ready ;) On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Use 1.2 as current now
Ok, I'll start a vote - this is important enough that we should do a vote. regards, Martin On 4/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Jetty is also ready ;) On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Use 1.2 as current
Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current now
Erik, JSF 1.2 also requires 1.5 the MYFACES_1_1_X branch will stay w/ Java 1.4 (or 1.3; not sure what the spec wants). -M On 4/18/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: Sounds like a good idea. One question however: Tomcat 6 requires JDK 5. Does this mean that the trunk will drop JDK 1.4 compatibility? Regards, Erik-Berndt -Oorspronkelijk bericht- Van: Martin Marinschek [mailto:[EMAIL PROTECTED] Verzonden: woensdag 18 april 2007 10:07 Aan: MyFaces Development Onderwerp: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Use 1.2 as current
What is in head that needs to be merged with the 1.2 branch? Why not move head to 1.1.5_1 and move 1.2 to head? I'm rather worried that the spec compliance will go down drastically if there are extensive merges. thanks david jencks On Apr 18, 2007, at 1:35 AM, Martin Marinschek wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
+1 This will help to finish the 1.2 development. I am not sure about a complete merge of the head and the 1.2 branch (it is a lot of work!). Maybe I will put the 1.2 branch as trunk and apply fixes (maybe existing fixes in for 1.1) in the trunk as the issues arise?) However, if you want to tackle the merge, I am up for it... :-) Cheers Bruno On 18/04/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
On 18/04/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 This will help to finish the 1.2 development. I am not sure about a complete merge of the head and the 1.2 branch (it is a lot of work!). Maybe I will put the 1.2 branch as trunk and apply fixes (maybe Read I would put instead of I will :-) existing fixes in for 1.1) in the trunk as the issues arise?) However, if you want to tackle the merge, I am up for it... :-) Cheers Bruno On 18/04/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
:-) +1 On 4/18/07, Bruno Aranda [EMAIL PROTECTED] wrote: On 18/04/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 This will help to finish the 1.2 development. I am not sure about a complete merge of the head and the 1.2 branch (it is a lot of work!). Maybe I will put the 1.2 branch as trunk and apply fixes (maybe Read I would put instead of I will :-) existing fixes in for 1.1) in the trunk as the issues arise?) However, if you want to tackle the merge, I am up for it... :-) Cheers Bruno On 18/04/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Use 1.2 as current
+1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOBAGO-358) Popup-Background renders wrong size in IE
Popup-Background renders wrong size in IE - Key: TOBAGO-358 URL: https://issues.apache.org/jira/browse/TOBAGO-358 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.10 Environment: Internet Explorer 6 Reporter: Matthias Wronka If you open a popup in IE (I use version 6), the popup-background is narrower than the browser-window. Furthermore you can click on elements located on the right or bottom side. The attached screenshot shows this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Use 1.2 as current
Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
maven-metadata.xml look incorrect in repository
maven-metadata.xml for the myfaces-shared-tomahawk artifact of the repository [1] looks incorrect. Specifically the list of versions is missing other version in the repository. All of the MyFaces shared artifacts have the same issue. Paul Spencer [1] http://repo1.maven.org/maven2/org/apache/myfaces/shared/myfaces-shared-tomahawk/maven-metadata.xml
Need a MyFaces Product Environment matrix.
Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. Product\Spec | Java| Tomcat/Sevlet | | 1.4 | 1.5 | 1.6 | 5.0 | 5.5 | 6.0 | MyFaces | Y | Y | ? | Y | Y | ? | Tomahawk | Y | Y | ? | Y | Y | ? | Tobago | - | Y | ? | ? | ? | ? | Orchestra| ? | ? | ? | ? | ? | ? | I suspect this need to be on the MyFaces site. Paul Spencer
Re: Use 1.2 as current
+1 for making the 1.2 tag the main show. I'm pretty confident that merging is no longer an option. The code bases have been separate for more than six months and they are very different. Plenty commits from several of us have touched 30 or 40 files at a time. Dennis Byrne On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne
Re: Use 1.2 as current
Ok - first for merging: I'll try to do it, but will refrain from doing so if it gets too hard. We'll see if it works or if it doesn't. second for branches/tags/trunk renaming: I think that Manfred's suggestion has merits. We can go with this. regards, Martin On 4/18/07, Dennis Byrne [EMAIL PROTECTED] wrote: +1 for making the 1.2 tag the main show. I'm pretty confident that merging is no longer an option. The code bases have been separate for more than six months and they are very different. Plenty commits from several of us have touched 30 or 40 files at a time. Dennis Byrne On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOBAGO-357) tc:selectOneRadio and f:facet name=change is only executed if changed twice
[
https://issues.apache.org/jira/browse/TOBAGO-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489736
]
Guido Dubois commented on TOBAGO-357:
-
This happens only in IE, in Firefox it works accurate...
tc:selectOneRadio and f:facet name=change is only executed if changed
twice
-
Key: TOBAGO-357
URL: https://issues.apache.org/jira/browse/TOBAGO-357
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.10
Environment: winxp prof, tomcat 5.5.20, myfaces 1.1.6 snap
(16.04.2007), tobago 1.0.11 snap (16.04.2007)
Reporter: Guido Dubois
Initialy nothing is choosen. Then select the first one (N), nothing
happend. Select the second one (O), now the method is invoked and the radio
is setted to the first one (N). Set to the second (O) does nothing. Set
to the third (S), method is invoked and radio setted to second (O).
tc:selectOneRadio required=true
tc:selectItem itemValue=N itemLabel=Nord /
tc:selectItem itemValue=O itemLabel=East /
tc:selectItem itemValue=S itemLabel=South /
tc:selectItem itemValue=W itemLabel=West /
f:facet name=change
tc:command actionListener=#{bbg.value1Changed} /
/f:facet
/tc:selectOneRadio
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Use 1.2 as current
+1 non-binding Gary -- Original message -- From: Martin Marinschek [EMAIL PROTECTED] Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
+1 for Manfreds suggestion. 2007/4/18, Manfred Geiler [EMAIL PROTECTED]: Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Mathias
Re: Use 1.2 as current
Manfred's idea sounds good to me. I especially appreciate that it will cause minimal disruption. Best wishes, Paul On Apr 18, 2007, at 7:21 AM, Manfred Geiler wrote: Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Use 1.2 as current now
Martin, How complete is the work on 1.2? ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:07 AM To: MyFaces Development Subject: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current now
Kito, Here are the current unassigned issues as per Martin Haimberger's report to the list previously: MYFACES-1563 - Christoph will do that. MYFACES-1255 - Crosschecked with RI - Only javadoc MYFACES-1264 - Christoph will do that. MYFACES-1253 - Crosschecked with RI - Only javadoc and specification MYFACES-1204 - Martin (me) will check this. MYFACES-1236 - This issues is open. MYFACES-1251 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1434 - Martin (me) will do Add element deferred-value/method for elements in the taglibs MYFACES-1444 - patch available MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - patch available MYFACES-1564 - Christoph Ebner will do that. MYFACES-1220 - This issue is open. MYFACES-1221 - Martin (me) will test this with an own renderkit. MYFACES-1230 - Specification Request, someone should recheck this. MYFACES-1582 - patch available MYFACES-1584 - patch available MYFACES-1223 - low priority Cheers, Zubin. On 4/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: Martin, How complete is the work on 1.2? ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:07 AM To: MyFaces Development Subject: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current now
based on the TCK rules, we can only say, MyFaces hasn't passed it yet. On 4/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: Martin, How complete is the work on 1.2? ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:07 AM To: MyFaces Development Subject: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF 1.2 project status
Hey Martin, any updates here ? (any patches that are still sitting in jira ?) -M On 4/6/07, Martin Haimberger [EMAIL PROTECTED] wrote: Hi *, Nice greatings from Christoph Ebner and me. Now a short overview of the JSF 1.2 implementation status. We looked over the unassigned issues: MYFACES-1563 - Christoph will do that. MYFACES-1255 - Crosschecked with RI - Only javadoc MYFACES-1264 - Christoph will do that. MYFACES-1253 - Crosschecked with RI - Only javadoc and specification MYFACES-1204 - Martin (me) will check this. MYFACES-1236 - This issues is open. MYFACES-1251 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1434 - Martin (me) will do Add element deferred-value/method for elements in the taglibs MYFACES-1444 - patch available MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - patch available MYFACES-1564 - Christoph Ebner will do that. MYFACES-1220 - This issue is open. MYFACES-1221 - Martin (me) will test this with an own renderkit. MYFACES-1230 - Specification Request, someone should recheck this. MYFACES-1582 - patch available MYFACES-1584 - patch available MYFACES-1223 - low priority I hope this helps. Regards, Christoph Ebner and Martin Haimberger -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (MYFACES-1587) generated h.tld doesn't conform to schema
generated h.tld doesn't conform to schema - Key: MYFACES-1587 URL: https://issues.apache.org/jira/browse/MYFACES-1587 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The TLD at target/classes/META-INF/h.tld that is generated ( IIUC ) by the maven plugin does not conform to the schema it references http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd. See GERONIMO-3038 for an exhaustive list of parse errors. The file at core/impl/src/main/tld/myfaces_html.tld appears to be a more accurate version of this TLD but does not end up in the myfaces-impl jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Use 1.2 as current now
Will there be a clear process in place for those who are not using 1.2 yet to check and out and fix 1.1 issues? There's 80+ issues still open. My initial reaction was -1, but I'm tending more toward +1 now, so long as 1.1 development can continue fairly easily. I'm hoping to be able to switch to Java 1.5 in a month or two, but that's not yet an option. On 4/18/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
Manfred addressed my concerns that I just posted on the other thread. +1 On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote: Manfred's idea sounds good to me. I especially appreciate that it will cause minimal disruption. Best wishes, Paul On Apr 18, 2007, at 7:21 AM, Manfred Geiler wrote: Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Use 1.2 as current
+1 for making 1.2 current. +1 for Manfred's structure. Once things have settled down (after Martin's attempted/successful merge), I'm going to do another source code audit to ensure the licensing is all compliant. On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote: Manfred's idea sounds good to me. I especially appreciate that it will cause minimal disruption. Best wishes, Paul On Apr 18, 2007, at 7:21 AM, Manfred Geiler wrote: Yes. +1 for a switch But let's discuss the how first. Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 4/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 but without a merge of the 1.1 trunk into 1.2. We have to select each individual issue. That is quite time consuming and shouldn't be done with this step. What about this: move current trunk to a 1.1 branch and move current 1.2 branch to trunk. That is quite a small step without any side effects to the existing code base. Cheers, Mathias 2007/4/18, Martin Marinschek [EMAIL PROTECTED]: Hi *, this is a formal vote on using the 1.2 branch as current now. Steps in doing this: - branch the current head as 1.1.5_1 - merge down the 1.2 branch to current head (that will be a lot of work, I'll tackle it) my +1 for doing this right now. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Grant Smith
RE: Use 1.2 as current now
Thanks. I just want to make sure I have my story correct - I'm often training people who are using MyFaces and asking about 1.2 J. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * From: Zubin Wadia [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 10:27 AM To: MyFaces Development; [EMAIL PROTECTED] Subject: Re: Use 1.2 as current now Kito, Here are the current unassigned issues as per Martin Haimberger's report to the list previously: MYFACES-1563 - Christoph will do that. MYFACES-1255 - Crosschecked with RI - Only javadoc MYFACES-1264 - Christoph will do that. MYFACES-1253 - Crosschecked with RI - Only javadoc and specification MYFACES-1204 - Martin (me) will check this. MYFACES-1236 - This issues is open. MYFACES-1251 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1434 - Martin (me) will do Add element deferred-value/method for elements in the taglibs MYFACES-1444 - patch available MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - patch available MYFACES-1564 - Christoph Ebner will do that. MYFACES-1220 - This issue is open. MYFACES-1221 - Martin (me) will test this with an own renderkit. MYFACES-1230 - Specification Request, someone should recheck this. MYFACES-1582 - patch available MYFACES-1584 - patch available MYFACES-1223 - low priority Cheers, Zubin. On 4/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: Martin, How complete is the work on 1.2? ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:07 AM To: MyFaces Development Subject: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1574) HtmlOutputLink returns the wrong renderer type
[
https://issues.apache.org/jira/browse/MYFACES-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1574.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
Not sure when/how this was fixed but HtmlOutputLink returns the correct
renderer type now.
HtmlOutputLink returns the wrong renderer type
--
Key: MYFACES-1574
URL: https://issues.apache.org/jira/browse/MYFACES-1574
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Matthias Weßendorf
Fix For: 1.2.0-SNAPSHOT
The generated java src for javax.faces.component.html.HtmlOutputLink sets the
renderer type to javax.faces.Label :
public HtmlOutputLink()
{
setRendererType(javax.faces.Label);
}
It should instead set the renderer type to javax.faces.Link
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Need a MyFaces Product Environment matrix.
On 4/18/07, Paul Spencer [EMAIL PROTECTED] wrote: Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. ... I suspect this need to be on the MyFaces site. Well... then... add it. :) Seriously, we're a 'commit then review' project, and documentation is unlikely to be controversial. If you think it needs to be done but don't have time right now, open a JIRA issue and maybe someone else will pick it up. -- Wendy
[jira] Commented: (MYFACES-1350) selectOneRadio renders extra /tr after each option if layout=pageLayout
[ https://issues.apache.org/jira/browse/MYFACES-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489851 ] Tiago Rinck Caveden commented on MYFACES-1350: -- We also noticed that in our project here. It's causing us some issues too. selectOneRadio renders extra /tr after each option if layout=pageLayout --- Key: MYFACES-1350 URL: https://issues.apache.org/jira/browse/MYFACES-1350 Project: MyFaces Core Issue Type: Bug Reporter: Peace Software Priority: Minor org.apache.myfaces.renderkit.html.HtmlRadioRendererBase is rendering an extra /tr after each option if layout=pageDirection. The encode end method has a line which says if (pageDirectionLayout) writer.endElement(HTML.TR_ELEM); even though it hasn't started a tr. This is causing page layout issues for us. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1350) selectOneRadio renders extra /tr after each option if layout=pageLayout
[ https://issues.apache.org/jira/browse/MYFACES-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489854 ] Mike Kienenberger commented on MYFACES-1350: Submit the fix in the form of a unified diff patch, and it'll be fixed faster. selectOneRadio renders extra /tr after each option if layout=pageLayout --- Key: MYFACES-1350 URL: https://issues.apache.org/jira/browse/MYFACES-1350 Project: MyFaces Core Issue Type: Bug Reporter: Peace Software Priority: Minor org.apache.myfaces.renderkit.html.HtmlRadioRendererBase is rendering an extra /tr after each option if layout=pageDirection. The encode end method has a line which says if (pageDirectionLayout) writer.endElement(HTML.TR_ELEM); even though it hasn't started a tr. This is causing page layout issues for us. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RESUT] Re: [Vote] accepting Trinidad as a subproject
thanks for voting. We got 13 +1 (12 binding) I'll follow up w/ a vote on the [EMAIL PROTECTED] for the Trinidad graduation. -Matthias On 4/17/07, Grant Smith [EMAIL PROTECTED] wrote: +1 On 4/17/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 2007/4/17, Gary VanMatre [EMAIL PROTECTED]: +1 non-binding Gary VanMatre From: Matthias Wessendorf [EMAIL PROTECTED] Hi, the Trinidad community has voted to graduate and being a subproject of the Apache MyFaces project ([1]). Now it's up to the MyFaces PMC to accept Trinidad as a subproject. Please cast your votes. -Matthias [1] http://mail-archive.com/adffaces-dev%40incubator.apache.org/msg02417.html -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Mathias -- Grant Smith -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (MYFACES-1588) managed beans are not resolved when scope is none
managed beans are not resolved when scope is none
---
Key: MYFACES-1588
URL: https://issues.apache.org/jira/browse/MYFACES-1588
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
When a manged bean is defined in an application's config like this:
managed-bean
managed-bean-nameMyBean/managed-bean-name
managed-bean-classfoo.MyBean/managed-bean-class
managed-bean-scopenone/managed-bean-scope
/managed-bean
the bean should be resolvable from a ValueBinding but instead it returns null
as shown below:
ValueBinding binding = application.createValueBinding(#{MyBean});
binding.getValue(facesContext); // returns null;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
Re: Need a MyFaces Product Environment matrix.
I havea added an small matrix to the following wiki page: http://wiki.apache.org/myfaces/CompatibilityMatrix if any body is sure about any combination he/she may edit it till the jira issue is solved. regards On 4/18/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/18/07, Paul Spencer [EMAIL PROTECTED] wrote: Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. ... I suspect this need to be on the MyFaces site. Well... then... add it. :) Seriously, we're a 'commit then review' project, and documentation is unlikely to be controversial. If you think it needs to be done but don't have time right now, open a JIRA issue and maybe someone else will pick it up. -- Wendy -- Arash Rajaeeyan
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
I don't think anyone has run the cactus tests in about six months. They
aren't a part of the CI loop either.
Dennis Byrne
On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote:
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
--
Dennis Byrne
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
right,
I think they used to be Bill's sandbox ;)
-M
On 4/18/07, Dennis Byrne [EMAIL PROTECTED] wrote:
I don't think anyone has run the cactus tests in about six months. They
aren't a part of the CI loop either.
Dennis Byrne
On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote:
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL:
http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
---
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
(original)
+++
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean,
facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean,
facesContext);
+}
}
return null;
--
Dennis Byrne
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r530154 - /myfaces/core/branches/jsf12/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java
Hi Paul,
if you do the first change (introduce a scope where put does nothing),
I don't see why the second one needs to be done - putting will do
nothing, so you don't need the extra-check for none, right?
regards,
Martin
On 4/18/07, Paul McMahan [EMAIL PROTECTED] wrote:
Just wanted to invite some peer review for this change I just
committed for MYFACES-1588. The problem was that managed beans in
scope none weren't accessible via the resolver. The change I made
passes the test cases but there might be a more elegant way to
implement it.
Also, I have an update for the ValueBindingImplCactus.java test case
to check for this bug (looked like a good place for it) but I
couldn't figure out how to run cactus from maven. Does that work OK
and if so can anyone provide tips on how to execute?
Best wishes,
Paul
On Apr 18, 2007, at 4:53 PM, [EMAIL PROTECTED] wrote:
Author: pmcmahan
Date: Wed Apr 18 13:53:26 2007
New Revision: 530154
URL: http://svn.apache.org/viewvc?view=revrev=530154
Log:
MYFACES-1588 resolve managed beans in scope none
Modified:
myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
Modified: myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java
URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/
src/main/java/org/apache/myfaces/el/unified/resolver/
ManagedBeanResolver.java?view=diffrev=530154r1=530153r2=530154
==
--- myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java (original)
+++ myfaces/core/branches/jsf12/impl/src/main/java/org/apache/
myfaces/el/unified/resolver/ManagedBeanResolver.java Wed Apr 18
13:53:26 2007
@@ -74,15 +74,6 @@
extContext.getApplicationMap().put(name, obj);
}
});
-s_standardScopes.put(
-none,
-new Scope()
-{
-public void put(ExternalContext extContext, String
name, Object obj)
-{
-// do nothing
-}
-});
}
/**
@@ -156,8 +147,13 @@
ManagedBean managedBean = runtimeConfig
(context).getManagedBean(strProperty);
if (managedBean != null) {
-storeManagedBean(managedBean, facesContext(context));
+FacesContext facesContext = facesContext(context);
context.setPropertyResolved(true);
+if (none.equals(managedBean.getManagedBeanScope())) {
+return beanBuilder.buildManagedBean(facesContext,
managedBean);
+} else {
+storeManagedBean(managedBean, facesContext);
+}
}
return null;
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Need a MyFaces Product Environment matrix.
I have updated the compatibility pages on the MyFaces website. The matrix has also been removed from the wiki page, so the data is in one place. Paul Spencer Arash Rajaeeyan wrote: I havea added an small matrix to the following wiki page: http://wiki.apache.org/myfaces/CompatibilityMatrix if any body is sure about any combination he/she may edit it till the jira issue is solved. regards On 4/18/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/18/07, Paul Spencer [EMAIL PROTECTED] wrote: Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. ... I suspect this need to be on the MyFaces site. Well... then... add it. :) Seriously, we're a 'commit then review' project, and documentation is unlikely to be controversial. If you think it needs to be done but don't have time right now, open a JIRA issue and maybe someone else will pick it up. -- Wendy No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.5.2/766 - Release Date: 4/18/2007 7:39 AM
