[Trinidad] 1.2.14 and new skin
Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] 1.2.14 and new skin
Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro
[jira] Updated: (TRINIDAD-1681) Generated Facelets taglib.xml files contain the OLD DTD
[ https://issues.apache.org/jira/browse/TRINIDAD-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1681: - Resolution: Fixed Fix Version/s: 2.0.1-plugins Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) Applied the patch; I also changed the -base file, for the merge info Generated Facelets taglib.xml files contain the OLD DTD --- Key: TRINIDAD-1681 URL: https://issues.apache.org/jira/browse/TRINIDAD-1681 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-plugins Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 2.0.1-plugins Attachments: declaration.diff The currently generated artifacts use the old DTD: ?xml version=1.0 encoding=utf-8? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib xmlns=http://java.sun.com/JSF/Facelet; However, as of JSF 2.0 it has to be: facelet-taglib xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd; version=2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] 1.2.14 and new skin
or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[Trinidad2] current branches
Hi, as a FYI (b/c some merging etc has been done): The maven-plugins location is (still) here: https://svn.apache.org/repos/asf/myfaces/trinidad-maven/branches/2.0.x-branch/ and the core is (still) here: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x/ However, both versions have been updated (as their pom.xml says)... -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] 1.2.14 and new skin
Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro
Re: [Trinidad] 1.2.14 and new skin
kick ass! great! On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Trinidad: nightly builds
Hi, the last nightly build is from 9th of February. Why is there no newer nightly build? -- Kind regards Mathias
[Vote] Trinidad plugins 2.0.1 release
Hi, I was running the needed tasks to get the 2.0.1 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. yes, it contains this fix: https://issues.apache.org/jira/browse/TRINIDAD-1681 The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.1 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad: nightly builds
teh continuum has some *problems* On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi, the last nightly build is from 9th of February. Why is there no newer nightly build? -- Kind regards Mathias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Vote] Trinidad plugins 2.0.1 release
+1 On Fri, Feb 12, 2010 at 11:07 AM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the 2.0.1 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. yes, it contains this fix: https://issues.apache.org/jira/browse/TRINIDAD-1681 The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.1 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: Trinidad: nightly builds
Hi again, Okay, Continuum has problems ... So I tried building Trinidad by myself with Maven 2.2.1. I'm sure it has worked a few month ago. But today I get the following warnings/errors: D:\Develop\Java\trinidadmvn -Dmaven.test.skip=true install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache MyFaces Trinidad 1.2 [INFO] Apache MyFaces Trinidad Build [INFO] Apache MyFaces Trinidad API [INFO] Apache MyFaces Trinidad Impl [INFO] Apache MyFaces Trinidad Examples [INFO] Apache MyFaces Trinidad Blank Demo [INFO] Apache MyFaces Trinidad Demo [INFO] Apache MyFaces Trinidad Components Showcase [INFO] [INFO] Building Apache MyFaces Trinidad 1.2 [INFO]task-segment: [install] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) Downloading: http://download.java.net/maven/1/org.apache.myfaces.trinidadbuild/poms/maven -xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository java.net (http://download.java.net/maven/1) Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.myfaces.trinidadbuild:maven-xrts-plugin Reason: POM 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin' not found in repository: Unable to download the artifact from any repository org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12 from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1) for project org.apache.myfaces.trinidadbuild:maven-xrts-plugin What did I made wrong? Or is this problem related to the new Trinidad Maven plugins? -- Kind regards, Mathias -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Friday, February 12, 2010 11:08 AM To: MyFaces Development Subject: Re: Trinidad: nightly builds teh continuum has some *problems* On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi, the last nightly build is from 9th of February. Why is there no newer nightly build? -- Kind regards Mathias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad: nightly builds
solved :), i committed that dependency a bit to fast ;-) (the vote for it is on the dev@) On Fri, Feb 12, 2010 at 11:17 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi again, Okay, Continuum has problems ... So I tried building Trinidad by myself with Maven 2.2.1. I'm sure it has worked a few month ago. But today I get the following warnings/errors: D:\Develop\Java\trinidadmvn -Dmaven.test.skip=true install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache MyFaces Trinidad 1.2 [INFO] Apache MyFaces Trinidad Build [INFO] Apache MyFaces Trinidad API [INFO] Apache MyFaces Trinidad Impl [INFO] Apache MyFaces Trinidad Examples [INFO] Apache MyFaces Trinidad Blank Demo [INFO] Apache MyFaces Trinidad Demo [INFO] Apache MyFaces Trinidad Components Showcase [INFO] [INFO] Building Apache MyFaces Trinidad 1.2 [INFO] task-segment: [install] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) Downloading: http://download.java.net/maven/1/org.apache.myfaces.trinidadbuild/poms/maven -xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository java.net (http://download.java.net/maven/1) Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.myfaces.trinidadbuild:maven-xrts-plugin Reason: POM 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin' not found in repository: Unable to download the artifact from any repository org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12 from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1) for project org.apache.myfaces.trinidadbuild:maven-xrts-plugin What did I made wrong? Or is this problem related to the new Trinidad Maven plugins? -- Kind regards, Mathias -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Friday, February 12, 2010 11:08 AM To: MyFaces Development Subject: Re: Trinidad: nightly builds teh continuum has some *problems* On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi, the last nightly build is from 9th of February. Why is there no newer nightly build? -- Kind regards Mathias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Trinidad: nightly builds
triggered the continuum; nightly is now from 2day On Fri, Feb 12, 2010 at 11:23 AM, Matthias Wessendorf mat...@apache.org wrote: solved :), i committed that dependency a bit to fast ;-) (the vote for it is on the dev@) On Fri, Feb 12, 2010 at 11:17 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi again, Okay, Continuum has problems ... So I tried building Trinidad by myself with Maven 2.2.1. I'm sure it has worked a few month ago. But today I get the following warnings/errors: D:\Develop\Java\trinidadmvn -Dmaven.test.skip=true install [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache MyFaces Trinidad 1.2 [INFO] Apache MyFaces Trinidad Build [INFO] Apache MyFaces Trinidad API [INFO] Apache MyFaces Trinidad Impl [INFO] Apache MyFaces Trinidad Examples [INFO] Apache MyFaces Trinidad Blank Demo [INFO] Apache MyFaces Trinidad Demo [INFO] Apache MyFaces Trinidad Components Showcase [INFO] [INFO] Building Apache MyFaces Trinidad 1.2 [INFO] task-segment: [install] [INFO] Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) Downloading: http://download.java.net/maven/1/org.apache.myfaces.trinidadbuild/poms/maven -xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository java.net (http://download.java.net/maven/1) Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trin idadbuild/maven-xrts-plugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-xrts-pl ugin/1.2.12/maven-xrts-plugin-1.2.12.pom [INFO] Unable to find resource 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12' in repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.myfaces.trinidadbuild:maven-xrts-plugin Reason: POM 'org.apache.myfaces.trinidadbuild:maven-xrts-plugin' not found in repository: Unable to download the artifact from any repository org.apache.myfaces.trinidadbuild:maven-xrts-plugin:pom:1.2.12 from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1) for project org.apache.myfaces.trinidadbuild:maven-xrts-plugin What did I made wrong? Or is this problem related to the new Trinidad Maven plugins? -- Kind regards, Mathias -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Friday, February 12, 2010 11:08 AM To: MyFaces Development Subject: Re: Trinidad: nightly builds teh continuum has some *problems* On Fri, Feb 12, 2010 at 10:59 AM, Mathias Walter mathias.wal...@gmx.net wrote: Hi, the last nightly build is from 9th of February. Why is there no newer nightly build? -- Kind regards Mathias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TOMAHAWK-1491) inputCalendar popupDateFormat renders incorrect popup
inputCalendar popupDateFormat renders incorrect popup
-
Key: TOMAHAWK-1491
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1491
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Calendar
Affects Versions: 1.1.9
Reporter: David Tarr
Priority: Minor
When the popupDateFormat is set to MM- or 01-MM- and after a value
is chosen through the popup calendar, after clicking on the image again the
previous month is selected.
t:inputCalendar value=#{theBean.thePojo.someDate}
binding=#{theBean.someDateInput}
converter=MMDateConverter
renderAsPopup=true
renderPopupButtonAsImage=true
popupDateFormat=MM- /
someDate is a Calendar. someDateInput is a UIInput. The converter is programmed
to match popupDateFormat.
1. Click on the popup image.
2. Select some date, say februari 15th 2010
3. See that the inputCalendar has it's value set to: 02-2010
4. Click on the popup image
5. See that the popup shows januari 31 2010 as selected value
(the behaviour is that it always has the last day of the previous month
selected)
When I replace the format with 01-MM- I have the same result. When I
replace the format with dd-MM- the popup works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832992#action_12832992 ] Leonardo Uribe commented on MYFACES-2543: - Ok, I'll do comments for each part: A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages? In other words, it says below are the criteria to define whether an application is compatible with facelets for jsf 2.0. Suppose you have an application/jsf component library working with facelets 1.1.x, so if you want to know if it is compatible or not with facelets for jsf 2.0 you have to ask this question first. ■ If the answer to this question is yes, Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to true. Please see Section 11.1.3 Application Configuration Parameters for details on this option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages. In other words it says if you have classes that uses com.sun.facelets package (read use as you have classes depending from), your application/jsf component library IS NOT compatible with facelets for jsf 2.0, but you can use the old facelets jars and register the old facelets view handler to keep using them as is. The other alternative is modify all clasess that uses com.sun.facelets and/or its sub-packages to the appropiate javax.faces.webapp.vdl counterpart. If you do that your application / jsf component library will work for jsf 2.0. The param is used to tell jsf please use the jsp view handler (JspViewHandlerImpl in myfaces case), because the other one introduced in jsf 2.0 (ViewHandlerImpl) could cause conflicts. Note that the only reason why an application / jsf component library could have a facelet taglib xml file is to reference classes that extends com.su.facelets package. ■ If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. If this is true, your application/ jsf component library already works for facelets in JSF 2.0. You can use it directly without make changes, but again that means there is no facelet taglib xml files. Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes. True My answer is no, we can't reopen this one, but I'll let it open to hear if someone in jsr-314-open list has something to say about it Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833000#action_12833000 ] Jakob Korherr commented on MYFACES-2543: I agree with Leonardo. Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Trinidad plugins 2.0.1 release
+1. Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 2.0.1 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. yes, it contains this fix: https://issues.apache.org/jira/browse/TRINIDAD-1681 The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.1 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/
[VOTE] Release of Trinidad 2.0.0-alpha2
Hi, I was running the needed tasks to get the second alpha release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 2.0.0-alpha2 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Trinidad 2.0.0-alpha2
+1 On Fri, Feb 12, 2010 at 3:15 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the second alpha release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 2.0.0-alpha2 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Trinidad 2.0.0-alpha2
+1 Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the second alpha release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 2.0.0-alpha2 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/
Re: [VOTE] Release of Trinidad 1.0.12
+1 Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.0.12 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 1.0.12 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-1.0.12_dist/
Re: [VOTE] Release of Trinidad 2.0.0-alpha2
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Matthias Wessendorf mat...@apache.org +1 On Fri, Feb 12, 2010 at 3:15 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the second alpha release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 2.0.0-alpha2 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Trinidad 1.0.12
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/11 Matthias Wessendorf mat...@apache.org +1 On Thu, Feb 11, 2010 at 10:28 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, I was running the needed tasks to get the 1.0.12 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 1.0.12 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-1.0.12_dist/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] 1.2.14 and new skin
Hello, I am trying to run the new demo with Trinidad 2.0. Unfortunately, nothing gets rendered. In web.xml, I use the following configuration for facelets: !-- Facelets configuration, comment to use JSP -- context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml/param-value !-- to run facelets for jspx files comment the line above and uncomment line below-- !--param-value*.xhtml;*.jspx/param-value-- /context-param context-param param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name param-valuetrue/param-value /context-param context-param param-namejavax.faces.FACELETS_LIBRARIES/param-name param-value/WEB-INF/tr-demo.taglib.xml/param-value /context-param Do you have any idea what other properties I should set? The TrinidadFilter gets entered, but no component is rendered. Do you, perhaps, have any example using facelets with Trinidad 2.0? Thank you! Marius On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf mat...@apache.orgwrote: kick ass! great! On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] 1.2.14 and new skin
the trinidad-demo works = cd to_the_dir; mvn jetty:run -PjettyConfig On Fri, Feb 12, 2010 at 3:27 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I am trying to run the new demo with Trinidad 2.0. Unfortunately, nothing gets rendered. In web.xml, I use the following configuration for facelets: !-- Facelets configuration, comment to use JSP -- context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml/param-value !-- to run facelets for jspx files comment the line above and uncomment line below-- !--param-value*.xhtml;*.jspx/param-value-- /context-param context-param param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name param-valuetrue/param-value /context-param context-param param-namejavax.faces.FACELETS_LIBRARIES/param-name param-value/WEB-INF/tr-demo.taglib.xml/param-value /context-param Do you have any idea what other properties I should set? The TrinidadFilter gets entered, but no component is rendered. Do you, perhaps, have any example using facelets with Trinidad 2.0? Thank you! Marius On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf mat...@apache.org wrote: kick ass! great! On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (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
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.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
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:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- 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.
-
You can reply to this email to add a comment to the issue online.
Re: [Vote] Trinidad plugins 2.0.1 release
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Max Starets max.star...@oracle.com +1. Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 2.0.1 release of the Apache MyFaces Trinidad Maven 2 Plugins. This contains more JSF 2.0 support for the MyFaces Trinidad Maven plugins. yes, it contains this fix: https://issues.apache.org/jira/browse/TRINIDAD-1681 The artifacts are deployed to my private Apache account ([1]). Please take a look at the 2.0.1 artifacts and vote. How to test those JARs ? Use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/staging_repo//url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed and tested the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/staging_repo/
Re: [Trinidad] 1.2.14 and new skin
I'm talking about the 2.0 version of Trinidad... On Fri, Feb 12, 2010 at 4:30 PM, Matthias Wessendorf mat...@apache.orgwrote: the trinidad-demo works = cd to_the_dir; mvn jetty:run -PjettyConfig On Fri, Feb 12, 2010 at 3:27 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I am trying to run the new demo with Trinidad 2.0. Unfortunately, nothing gets rendered. In web.xml, I use the following configuration for facelets: !-- Facelets configuration, comment to use JSP -- context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml/param-value !-- to run facelets for jspx files comment the line above and uncomment line below-- !--param-value*.xhtml;*.jspx/param-value-- /context-param context-param param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name param-valuetrue/param-value /context-param context-param param-namejavax.faces.FACELETS_LIBRARIES/param-name param-value/WEB-INF/tr-demo.taglib.xml/param-value /context-param Do you have any idea what other properties I should set? The TrinidadFilter gets entered, but no component is rendered. Do you, perhaps, have any example using facelets with Trinidad 2.0? Thank you! Marius On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf mat...@apache.org wrote: kick ass! great! On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[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-tabpanelfocusedCommentId=12833029#action_12833029
]
Jakob Korherr commented on MYFACES-2552:
I just found out why this happens: #{cc.attrs} resolves to a Map
(CompositeComponentAttributesMapWrapper) and thus javax.el.MapELResolver is
used to resolve the values. Here is the important part of the implementation of
the getType() method from Tomcat:
if (base instanceof Map?,?) {
context.setPropertyResolved(true);
Object obj = ((Map?,?) base).get(property);
return (obj != null) ? obj.getClass() : null;
}
This explains the behavior. So we can only circumvent this by not using a Map,
however I don't know if we should really change this...
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.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
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:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- 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.
-
You can reply to this email to add a comment to the issue online.
[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-tabpanelfocusedCommentId=12833040#action_12833040
]
Jakob Korherr commented on MYFACES-2552:
One solution for this would be to return a special type != Map when resolving
#{cc.attrs} and providing a special ELResolver for this type. Then we could use
the original ValueExpressions of the attributes from the composite component to
determine the type. Of course this would totally break the spec!!!
What are your opinions about that? Is this too unimportant to make such great
changes or should we consult the EG and maybe change this behavior? Maybe in
the next major release (2.1)?
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.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
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:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- 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.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad] 1.2.14 and new skin
same here On Fri, Feb 12, 2010 at 4:21 PM, Marius Petoi marius.pe...@codebeat.ro wrote: I'm talking about the 2.0 version of Trinidad... On Fri, Feb 12, 2010 at 4:30 PM, Matthias Wessendorf mat...@apache.org wrote: the trinidad-demo works = cd to_the_dir; mvn jetty:run -PjettyConfig On Fri, Feb 12, 2010 at 3:27 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I am trying to run the new demo with Trinidad 2.0. Unfortunately, nothing gets rendered. In web.xml, I use the following configuration for facelets: !-- Facelets configuration, comment to use JSP -- context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml/param-value !-- to run facelets for jspx files comment the line above and uncomment line below-- !--param-value*.xhtml;*.jspx/param-value-- /context-param context-param param-namejavax.faces.FACELETS_SKIP_COMMENTS/param-name param-valuetrue/param-value /context-param context-param param-namejavax.faces.FACELETS_LIBRARIES/param-name param-value/WEB-INF/tr-demo.taglib.xml/param-value /context-param Do you have any idea what other properties I should set? The TrinidadFilter gets entered, but no component is rendered. Do you, perhaps, have any example using facelets with Trinidad 2.0? Thank you! Marius On Fri, Feb 12, 2010 at 11:26 AM, Matthias Wessendorf mat...@apache.org wrote: kick ass! great! On Fri, Feb 12, 2010 at 10:20 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Ok, let's wait a little bit :), we are working on fixing the component showcase on the 2.0.x also. On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: or... we wait a bit. On the 2.0.x branch, I currently disabled the demo (as a fyi) But Skin I merged over! :) -Matthias On Fri, Feb 12, 2010 at 9:48 AM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Matthias, The skin is stable enough, there are no big issues with, but we are currently working on improving the skinning for some of the components. I guess this shouldn't stop a release of Trinidad IMHO. regards, Catalin On 2/12/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[core] facelets composite component + ValueExpression.getType()
Hi guys, Today I ran into a problem with ValueExpression.getType() when used in a facelets composite component. Please see MYFACES-2552 for details about this issue and a possible solution to it (which however would certainly break the spec). I would really appreciate your opinions to that. Thanks in advance! Regards, Jakob
[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-tabpanelfocusedCommentId=12833046#action_12833046
]
Jakob Korherr commented on MYFACES-2552:
For now I'll commit a very ugly temporal workaround for this. Note that mojarra
currently does the same thing as this workaround for this special scenario.
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.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
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:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-1708) issues with new Trinidad default skin - Casablanca
[ https://issues.apache.org/jira/browse/TRINIDAD-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Walter reopened TRINIDAD-1708: -- The fix is incomplete. As soon as one of the xxxGridVisible attributes are set to false, both horizontal and vertical grid lines are not drawn, even if the other yyyGridVisible attribute is set to false. I tried all combinations with treeTable. issues with new Trinidad default skin - Casablanca -- Key: TRINIDAD-1708 URL: https://issues.apache.org/jira/browse/TRINIDAD-1708 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.14-core Reporter: Mathias Walter Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: casablanca_TreeTable_actionsFacet.jpg Disabling gridlines (verticalGridVisible=false horizontalGridVisible=false) in table or treeTable does not work. Neither in FireFox nor in IE8. Can also be seen in the show case. Also, Trinidad input/select components are not rendered well if they are placed in the actions facet of a table/treeTable. See screenshot. The first input is a h:inputText, 2nd is tr:inputText and 3rd is tr:inputText with simple=true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
Handle MethodExpressions on composite:attribute correctly --- Key: MYFACES-2553 URL: https://issues.apache.org/jira/browse/MYFACES-2553 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr There are currently problems when composite:attribute refers to a MethodExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Ext-CDI] @Transactional
Hi folks, I saw the discussion of adding an @Transactional-Annotation to your CDI extensions. I think Gerhard wrote it. I wonder if it deals with JTA transactions (which indeed would be pretty straight-forward) or with EntityTransactions of an resource-local EntityManager. I am working on the latter one and just would want to know if someone else is working on such stuff. I think it would be great, when we could archive injection of resource-local EntityManagers with transaction-support to deploy it on a tomcat or jetty. What do you think? Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann
[jira] Created: (TRINIDAD-1720) Some border lines are not drawn with the new Casablanca skin
Some border lines are not drawn with the new Casablanca skin Key: TRINIDAD-1720 URL: https://issues.apache.org/jira/browse/TRINIDAD-1720 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.14-core Reporter: Mathias Walter The fix for Issue TRINIDAD-1708 introduced a new bug. Some horizontal and vertical border lines are not drawn, regardless of the xxxGridVisible attribute settings. See the attached screenshot. In the first tree table, the bottom line of the header is drawn for the node stamp only. For the remaining columns it is not drawn. In this case, I set horizontalGridVisible to false. In the second table (a plain tr:table, no xxxGridVisible attributes are set), the top and bottom line of the header is not drawn. Also no right border is drawn. Sometimes the bottom line is missing between two rows, too. The table inside the detailStamp is drawn correctly (in this case). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833087#action_12833087 ] Ganesh Jung commented on MYFACES-2543: -- Did you take into account jars with a taglib.xml that are based only on xhtml templates? I bet 95% of all Facelets taglibs do this. An application can be using the jar that I uploaded with this issue. Did you check it? It doesn't extend any com.sun.facelets stuff. In fact, it doesn't use any Java classes at all... DojoFaces also *is* this kind of jar. It has an old style taglib.xml and it consists solely of xhtml templates. According to the spec it *must* work with a JSF 2.0 conform implemetation, but with MyFaces 2.0 beta 2 not even the taglib.xml will be accepted... Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1721) pathStamp in treeTable to large with Casablanca skin
pathStamp in treeTable to large with Casablanca skin Key: TRINIDAD-1721 URL: https://issues.apache.org/jira/browse/TRINIDAD-1721 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.14-core Reporter: Mathias Walter The pathStamp of a treeTable is rendered too long and too height. See the attached screenshot. The height should be the same as the font height or the header height. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [Trinidad] 1.2.14 and new skin
Hi, the skin has still a few bugs. I'll test it with different applications further. -- Kind regards, Mathias -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Friday, February 12, 2010 9:32 AM To: MyFaces Development Subject: [Trinidad] 1.2.14 and new skin Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833094#action_12833094 ] Matthias Weßendorf commented on MYFACES-2543: - Leo/Jakob: check the JAR before you comment... There is NO java class at all; just some taglib and XHTML this has to work. Why? Here: Question: is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages? == NO (right?) From the spec: If the answer to this question is no, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. == should work. But it does not... why? Myfaces2 wants to see 2.0 gramma settings on taglib (which is wrong) The XSD restriction on the SPEC appendix is a bug. I am re-opening this ticket, for the given reasons. Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] 1.2.14 and new skin
cool; so let's wait a bit On Fri, Feb 12, 2010 at 7:00 PM, Mathias Walter mathias.wal...@gmx.net wrote: Hi, the skin has still a few bugs. I'll test it with different applications further. -- Kind regards, Mathias -Original Message- From: mwessend...@gmail.com [mailto:mwessend...@gmail.com] On Behalf Of Matthias Wessendorf Sent: Friday, February 12, 2010 9:32 AM To: MyFaces Development Subject: [Trinidad] 1.2.14 and new skin Hey Catalin, what is your take on the new skin? Is it stable enough for a 1.2.14 release? I'd not mind to generate stuff for it over the weekend. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] PPR and AJAX
Hi Werner - On Fri, Feb 12, 2010 at 2:28 AM, Werner Punz werner.p...@gmail.com wrote: Werner Punz schrieb: Ok I shot over the top a little bit early, the problem with file input is that you cannot cover it within the bounds of XHR at all you have to revert to an iframe transport. Yep. I raised this requirement a number of times as well since it is a requirement for both Trinidad and ADF Faces. Actually, my hope was that jsf.ajax.request() API was sufficiently generic to allow alternate transport implementations and I had assumed that the JSF implementations would be able to provide iframe-based postback support as an implementation detail. However, Andrew Robinson recently pointed out that there is one case where the JSF client-side API introduces an XHR dependency: jsf.ajax.response() expects an XHR object, which it uses to grab the responseXML. FWIW, Jim logged the following spec issue to track the general requirement: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=647 I have updated the issue with a comment about the jsf.ajax.response() XHR dependency. Are you aware of other such dependencies? If so, we should capture these in the spec issue as well. Note that it still seems possible for JSF implementations to provide iframe-based postback solutions, though might require a bit of hackery... Since the jsf.ajax.response() implementation expects to be able to retrieve the responseXML off of the XHR object, one possible approach might be for jsf.ajax.request() to mock up its own pseudo-XHR object which provides access to the response document from the iframe. Andrew R actually thought of this a way to allow us to delegate back to jsf.ajax.response() in Trinidad in the case where we use Trinidad's iframe-based postback mechanism. Perhaps if this works out well, we can incorporate such a solution back into MyFaces? Andy
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833105#action_12833105 ] Leonardo Uribe commented on MYFACES-2543: - That's another completely different use case. Ganesh, could you describe in more detailed and complete way what's your proposal about what a jsf implementation should do (not your particular use case, instead what jsf should do when it founds a facelets taglib file) and submit it to jsr-314-open list. It is not clear this specific use case from your comments. Probe of that is your last comment make clear your point of view. Note if that is true, the spec should say something about that. Also, RI behavior should be make clear first, because there are doubts about whether read facelets taglibs 1.1.x is a bug or not (I'm supposing right now it is a bug, but I don't know RI internals). Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1397) selectManyShuttle inside panelBox corrupts class attributes of panelBox cells
[ https://issues.apache.org/jira/browse/TRINIDAD-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833107#action_12833107 ] Jeanne Waldman commented on TRINIDAD-1397: -- Hi, I get errors when I apply this patch, probably because of you have the file SelectManyShuttleRendererOrig.java. --- SelectManyShuttleRendererOrig.java 2009-09-11 13:26:10.0 +0200 +++ SelectManyShuttleRenderer.java 2009-09-11 12:53:14.0 +0200 It is a simple enough file that I can probably figure out how to merge in your changes, but in the future make sure the patch works. Thanks! Jeanne selectManyShuttle inside panelBox corrupts class attributes of panelBox cells -- Key: TRINIDAD-1397 URL: https://issues.apache.org/jira/browse/TRINIDAD-1397 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.10-core, 1.2.11-core, 1.2.12-core, 1.2.13-core Environment: Java 1.5 MyFaces 1.2.X Trinidad 1.2.10 / 1.2.11 / 1.2.12 / 1.2.13 Tomcat 6.0.18 / 6.0.14 Reporter: elmar kretzer Assignee: Jeanne Waldman Attachments: patchfile.txt When a selectManyShuttle is rendered inside a panelBox, the panelBox content cells got corrupted css class attributes ?xml version=1.0 encoding=UTF-8 ? jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trh=http://myfaces.apache.org/trinidad/html; jsp:directive.page contentType=text/html; charset=utf-8 / f:view trh:html trh:head title=test /trh:head trh:body tr:form tr:panelBox tr:selectOrderShuttle f:selectItem itemLabel=test itemValue=test / /tr:selectOrderShuttle /tr:panelBox /tr:form /trh:body /trh:html /f:view /jsp:root will lead to following html: td class=af_panelBox_start/td td class=af_panelBox_body.../td td class=af_selectManyShuttle_box_end/td -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of Trinidad 2.0.0-alpha2
+1 Gerhard Petracek wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 On Fri, Feb 12, 2010 at 3:15 PM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: Hi, I was running the needed tasks to get the second alpha release of the Apache MyFaces Trinidad 2.x CORE out. The artifacts are deployed to my private Apache account ([1]). The distribution is located at [2]. Please take a look at the 2.0.0-alpha2 artifacts and vote [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ http://people.apache.org/%7Ematzew/staging_repo/ [2] http://people.apache.org/~matzew/trinidad-2.0.0-alpha2_dist/ http://people.apache.org/%7Ematzew/trinidad-2.0.0-alpha2_dist/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Ext-CDI] @Transactional
hi arne, yes - i used EntityTransaction in the prototype and it works pretty well in a servlet container (that was the base idea). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/12 Arne Limburg arne.limb...@openknowledge.de Hi folks, I saw the discussion of adding an @Transactional-Annotation to your CDI extensions. I think Gerhard wrote it. I wonder if it deals with JTA transactions (which indeed would be pretty straight-forward) or with EntityTransactions of an resource-local EntityManager. I am working on the latter one and just would want to know if someone else is working on such stuff. I think it would be great, when we could archive injection of resource-local EntityManagers with transaction-support to deploy it on a tomcat or jetty. What do you think? Regards, Arne -- Arne Limburg - Enterprise Developer OpenKnowledge GmbH, Oldenburg Bismarckstraße 13, 26122 Oldenburg Mobil: +49 (0) 151 - 108 22 942 Tel: +49 (0) 441 - 4082-0 Fax: +49 (0) 441 - 4082-111 arne.limb...@openknowledge.de http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670 Geschäftsführer: Lars Röwekamp, Jens Schumann
[jira] Commented: (TRINIDAD-1397) selectManyShuttle inside panelBox corrupts class attributes of panelBox cells
[ https://issues.apache.org/jira/browse/TRINIDAD-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833130#action_12833130 ] Matthias Weßendorf commented on TRINIDAD-1397: -- I think that's our failure, as the patch is already sitting there since a while ;-) selectManyShuttle inside panelBox corrupts class attributes of panelBox cells -- Key: TRINIDAD-1397 URL: https://issues.apache.org/jira/browse/TRINIDAD-1397 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.10-core, 1.2.11-core, 1.2.12-core, 1.2.13-core Environment: Java 1.5 MyFaces 1.2.X Trinidad 1.2.10 / 1.2.11 / 1.2.12 / 1.2.13 Tomcat 6.0.18 / 6.0.14 Reporter: elmar kretzer Assignee: Jeanne Waldman Attachments: patchfile.txt When a selectManyShuttle is rendered inside a panelBox, the panelBox content cells got corrupted css class attributes ?xml version=1.0 encoding=UTF-8 ? jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trh=http://myfaces.apache.org/trinidad/html; jsp:directive.page contentType=text/html; charset=utf-8 / f:view trh:html trh:head title=test /trh:head trh:body tr:form tr:panelBox tr:selectOrderShuttle f:selectItem itemLabel=test itemValue=test / /tr:selectOrderShuttle /tr:panelBox /tr:form /trh:body /trh:html /f:view /jsp:root will lead to following html: td class=af_panelBox_start/td td class=af_panelBox_body.../td td class=af_selectManyShuttle_box_end/td -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2551) Set charset=iso-8859-1 using f:view in facelets page makes current page not being rendered
[ https://issues.apache.org/jira/browse/MYFACES-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2551. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 The encoding of the document takes precedence over contentType or encoding param from f:view, but if no xml declaration is used (like in mojarra examples), the value from contentType must be used as the response encoding (right now encoding or charset param set in contentType is just ignored). The original facelets code sets encoding always UTF-8. It was asked to jsr-314-open list about that, but I think we can apply the proposed behavior without problem. Set charset=iso-8859-1 using f:view in facelets page makes current page not being rendered Key: MYFACES-2551 URL: https://issues.apache.org/jira/browse/MYFACES-2551 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha, 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Pages starting like this: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; f:view contentType=text/html; charset=iso-8859-1/ are not rendered. If we remove charset=iso-8859-1, it works again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
[
https://issues.apache.org/jira/browse/MYFACES-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833178#action_12833178
]
Leonardo Uribe commented on MYFACES-2553:
-
Testing mojarra example ajax-component/switchlistComponent.jsf
The use of the composite component is this:
ez:switchlist id=switchlist selected1=#{switchlist.list1}
selected2=#{switchlist.list2}
items1=#{switchlist.items1}
items2=#{switchlist.items2}
move1to2=#{switchlist.move1to2}
move2to1=#{switchlist.move2to1}/
The composite component has something like this in its declaration:
cc:attribute name=move1to2 targets=move1to2 required=true
method-signature=void f1(javax.faces.event.ActionEvent) /
inside cc:implementation it has something like this:
h:commandButton id=move1to2 value=gt;gt;
actionListener=#{cc.attrs.move1to2} styleClass=switchlistButton/
When the page is rendered, the following message is shown below:
com.sun.faces.application.view.FaceletViewHandlingStrategy
retargetMethodExpressions
WARNING: JSF1092: Composite Component: switchlist.xhtml, library: switchlist :
Unnecessary specification of the 'targets' attribute for composite attribute
'move2to1'. The 'targets' attribute is only necessary when the composite
attribute is named 'action', 'actionListener', 'validator', or
'valueChangeListener'.
Checking myfaces, the attribute is retarget to h:commandButton, but on
attribute move1to2.
To make this work, the attribute must not be retarget, but it is not very clear
what should happen instead. It seems according to the warning there is some
missing undocumented detail on
ViewDeclarationLanguage.retargetMethodExpressions that do something.
Suggestions are welcome.
Handle MethodExpressions on composite:attribute correctly
---
Key: MYFACES-2553
URL: https://issues.apache.org/jira/browse/MYFACES-2553
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
There are currently problems when composite:attribute refers to a
MethodExpression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1722) Trinidad 2: Wrong locale rule used in skinng
Trinidad 2: Wrong locale rule used in skinng Key: TRINIDAD-1722 URL: https://issues.apache.org/jira/browse/TRINIDAD-1722 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets To reproduce the issue, run table.jspx in Firefox with the latest 2.0.x branch. Notice that the font size is huge. For some strange reason, the skin picks up the following Thai locale rule in base-desktop.xss: !-- And on Thai Gecko - see bug 3897341 - bump the font size up -- styleSheet platforms=windows linux browsers=gecko locales=th style name=AFDefaultFontFamily property name=font-familyBrowallia New,Arial,Helvetica,Geneva,sans-serif/property property name=font-size16pt/property /style If you remove the rule, everything runs fine. If you use IE, it works fine too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1723) Trinidad 2: ClassCastEXception while running componentDemos.jspx
Trinidad 2: ClassCastEXception while running componentDemos.jspx Key: TRINIDAD-1723 URL: https://issues.apache.org/jira/browse/TRINIDAD-1723 Project: MyFaces Trinidad Issue Type: Bug Components: Archetype Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Grab the latest trinidad-2.0.x branch and try running componentDemos.jspx. The following exception will be thrown: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode cannot be cast to org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.__getAdapter(UIXComponentUINode.java:439) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:65) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:852) at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:509) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:531) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:70) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:153) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:546) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:82) This does not seem to be JSF 2 specific, but I have not had time to try it on the latest MAIN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1724) Generated Facelets taglib.xml files don't validate against schema
Generated Facelets taglib.xml files don't validate against schema - Key: TRINIDAD-1724 URL: https://issues.apache.org/jira/browse/TRINIDAD-1724 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.2-plugins Reporter: Catalin Kormos At least the tr.taglib.xml I just checked and it contains a lot of method-signature elements, for example: attribute description an EL binding to the method that will deliver the file contents. The method must take two parameters, a FacesContext and an OutputStream. /description namemethod/name requiredtrue/required method-signaturevoid myMethod(javax.faces.context.FacesContext, java.io.OutputStream)/method-signature /attribute Checking the schema method-signature is not allowed in attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ExtVal] backward compatibility
hi, there is no perfect solution for it (imo). (due to the limited amount of possibilities (esp. due to the quite long name of the base package).) so i think we should keep the original/current structure. i'm currently testing extval r3 in quite different constellations. i plan to prepare the 3rd release in about 3 weeks. so there is still some time to review it. the project grew a lot - we should take the time to review it until the vote. there will be no new features until the release. so you can extensively test the current version available in the svn (or the latest milestone which is quite similar). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/3 Gerhard Petracek gerhard.petra...@gmail.com hi rudy, in case of SkipValidationStrategy you are right - it has to be moved as well. JoinValidationStrategy will be removed after some final tests. (it was replaced by JoinValidationMetaDataStorageFilter which is based on the new storage concept and offers a better performance.) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/3 Rudy De Busscher rdebussc...@gmail.com Hi Gerhard, +1 but maybe a few remarks - When the refactorings are only cosmetic (like here, there is a better grouping of functional alike classes), the user of the library hasn't much benefit from it. And thus doesn't like it very much. - By moving the annotation (JoinValidation, SkipValidation), the strategy must be moved along, no ? - JoinValidationStrategy is marked deprecated, (commit related to EXTVAL-59 and EXTVAL-60, don't see the immediate link between the deprecated and the issue, but anyway) - So skipValidation is the only x.x.2 moved file, together with the CrossValidationStorageEntry indicated on the upgrade guide. - Moving classes between packages is seen during compile time of the project. So, although not pleasant for the user, it is more visible then the functional changes of the @Length and the @Pattern. So only one 'feature' skipValidation impacted and already done other similar things, so +1 regards, Rudy On 3 February 2010 14:49, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi @ all, the review phase for the next extval release (r3) has been started already. one important topic is backward compatibility. the 3rd release will be a major version. besides a lot of new features r3 will be the first version which offers bean-validation integration for all jsf versions. i created an upgrade guide [1] for collecting changes which aren't backward compatible. currently there are just very few changes in the property-validation module which are easy to fix. since r3 will be a major release and i know many people who started with the current milestone and not the previous version, i think we can take the chance for further restructurings in the validation modules. what's about the following suggestion? i would like to introduce a new package which is suggested for every validation module for shared/common stuff. the name is e.g. module and in case of the property-validation module it would be interesting to move some classes to this package. property-validation module: org.apache.myfaces.extensions.validator.module.property [new] |_ PropertyValidationModuleKey [new] |_ PropertyValidationSkipValidationEvaluator [new] |_ annotation ||_ JoinValidation [moved] ||_ SkipValidation [moved] ||_ SkipValidationSupport [moved] |__ initializer.component [new] ||_ HtmlCoreComponentsComponentInitializer [moved] |__ interceptor [new] | |_ PropertyValidationInterceptor [moved] |__ startup [new] | |_ PropertyValidationModuleStartupListener [moved] |__ storage [new] |__ mapper [new] ||__ PropertyValidationGroupStorageNameMapper [new] |__ JoinValidationMetaDataStorageFilter [new] most of the stuff is new or internal - so we don't really have an issue here. however, esp. JoinValidation, SkipValidation and SkipValidationSupport are not new and part of the api. if we move these annotations (because they are used in base- as well as in cross-validation), users have to fix some import statements. since these annotations aren't used extremely often it does not lead to a huge effort. to be consistent we would have the same package concept in the bean-validation module as well (org.apache.myfaces.extensions.validator.module.bean). in this case we don't have an issue because the module is completely new. since it is a major release (imo) the impact is minimal and should be ok. if there is no veto, i'll do the mentioned refactoring. (for sure - i'll also create a jira issue.) regards, gerhard [1]
[jira] Commented: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
[ https://issues.apache.org/jira/browse/MYFACES-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833252#action_12833252 ] Leonardo Uribe commented on MYFACES-2553: - It seems there is a misunderstanding about the javadoc. It says: Otherwise, assume that the MethodExpression should be placed in the components attribute set. The runtme must create the MethodExpression instance based on the value of the method-signature attribute. It has sense the related component attribute set is the one from the composite, not the one pointed by targets property, because this property is only valid for the previous four attributes. Unfortunately, this does not solve the problem. Doing some tests, the code try to find a method called move1to2, with base object as cc.attrs map. We can't do anything from CompositeComponentELResolver because we don't have the property that should be retrieved from the map, and the method is invoked internally. It is clear we have to do something from before the original MethodExpression created by the current ExpressionFactory invoked. Debugging the code from where the event is invoked (UICommand.broadcast) the closest point is org.apache.myfaces.view.facelets.el.TagMethodExpression. This class is created from TagAttributeImpl.getMethodExpression() and wraps the original MethodExpression. This is not going to be an easy workaround .. Suggestions are welcome. Handle MethodExpressions on composite:attribute correctly --- Key: MYFACES-2553 URL: https://issues.apache.org/jira/browse/MYFACES-2553 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr There are currently problems when composite:attribute refers to a MethodExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
[ https://issues.apache.org/jira/browse/MYFACES-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833253#action_12833253 ] Leonardo Uribe commented on MYFACES-2553: - It seems there is a misunderstanding about the javadoc. It says: Otherwise, assume that the MethodExpression should be placed in the components attribute set. The runtme must create the MethodExpression instance based on the value of the method-signature attribute. It has sense the related component attribute set is the one from the composite, not the one pointed by targets property, because this property is only valid for the previous four attributes. Unfortunately, this does not solve the problem. Doing some tests, the code try to find a method called move1to2, with base object as cc.attrs map. We can't do anything from CompositeComponentELResolver because we don't have the property that should be retrieved from the map, and the method is invoked internally. It is clear we have to do something from before the original MethodExpression created by the current ExpressionFactory invoked. Debugging the code from where the event is invoked (UICommand.broadcast) the closest point is org.apache.myfaces.view.facelets.el.TagMethodExpression. This class is created from TagAttributeImpl.getMethodExpression() and wraps the original MethodExpression. This is not going to be an easy workaround .. Suggestions are welcome. Handle MethodExpressions on composite:attribute correctly --- Key: MYFACES-2553 URL: https://issues.apache.org/jira/browse/MYFACES-2553 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr There are currently problems when composite:attribute refers to a MethodExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1724) Generated Facelets taglib.xml files don't validate against schema
[ https://issues.apache.org/jira/browse/TRINIDAD-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833269#action_12833269 ] Max Starets commented on TRINIDAD-1724: --- The XSD shipped with Mojarra 2.0.1 (under jsf-api/doc) contains the following: xsd:element name=method-signature type=javaee:string minOccurs=0 xsd:annotation xsd:documentation Defines the method signature for a MethodExpression- enabled attribute. /xsd:documentation /xsd:annotation /xsd:element However, the one available from http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd does not. I suspect Mojarra guys forgot to update it. If the omission is intentional, we can stop genetating method-signature elements. Generated Facelets taglib.xml files don't validate against schema - Key: TRINIDAD-1724 URL: https://issues.apache.org/jira/browse/TRINIDAD-1724 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.2-plugins Reporter: Catalin Kormos At least the tr.taglib.xml I just checked and it contains a lot of method-signature elements, for example: attribute description an EL binding to the method that will deliver the file contents. The method must take two parameters, a FacesContext and an OutputStream. /description namemethod/name requiredtrue/required method-signaturevoid myMethod(javax.faces.context.FacesContext, java.io.OutputStream)/method-signature /attribute Checking the schema method-signature is not allowed in attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1723) Trinidad 2: ClassCastEXception while running componentDemos.jspx
[ https://issues.apache.org/jira/browse/TRINIDAD-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833270#action_12833270 ] Max Starets commented on TRINIDAD-1723: --- Could you try running in JDev after generating workspace with 'mvn jdev:jdev'? Trinidad 2: ClassCastEXception while running componentDemos.jspx Key: TRINIDAD-1723 URL: https://issues.apache.org/jira/browse/TRINIDAD-1723 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Grab the latest trinidad-2.0.x branch and try running componentDemos.jspx. The following exception will be thrown: java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode cannot be cast to org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode at org.apache.myfaces.trinidadinternal.uinode.UIXComponentUINode.__getAdapter(UIXComponentUINode.java:439) at org.apache.myfaces.trinidadinternal.uinode.UINodeRendererBase.encodeEnd(UINodeRendererBase.java:65) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:852) at org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:509) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:531) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:70) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:153) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:546) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:82) This does not seem to be JSF 2 specific, but I have not had time to try it on the latest MAIN. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2553) Handle MethodExpressions on composite:attribute correctly
[ https://issues.apache.org/jira/browse/MYFACES-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2553. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Assignee: Leonardo Uribe (was: Jakob Korherr) I committed a fast and simple solution. The idea is detect when we have this indirection case and if so, create a wrapper that deal with this case, getting the value from the map and then invoking the required MethodExpression. Handle MethodExpressions on composite:attribute correctly --- Key: MYFACES-2553 URL: https://issues.apache.org/jira/browse/MYFACES-2553 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 There are currently problems when composite:attribute refers to a MethodExpression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-tabpanelfocusedCommentId=12833297#action_12833297
]
Leonardo Uribe commented on MYFACES-2552:
-
I think the only thing we can do is assume this case return null and deal with
it, retrieving the real value and check its type. It is possible to change the
ELResolver (Flash object implements Map but FlashELResolver resolve its values,
instead MapELResolver).
In this example there is no way to check the type without retrieve the value,
and note #{cc.attrs} is a MapString,Object. I remember variants of the same
issue long time ago on myfaces and in that time the solution was the same.
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.0.0-beta-2
Reporter: Jakob Korherr
Assignee: Jakob Korherr
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:
cc:interface name=mycomponent
cc:attribute name=test required=true/
/cc:interface
cc:implementation
h:selectManyListbox value=#{cc.attrs.test}
f:selectItems value=#{some select items}/
/h:selectManyListbox
/cc:implementation
-- 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.
-
You can reply to this email to add a comment to the issue online.
