[jira] Created: (TOBAGO-973) Disabled Button/Link does not use the Disabled Icon
Disabled Button/Link does not use the Disabled Icon - Key: TOBAGO-973 URL: https://issues.apache.org/jira/browse/TOBAGO-973 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.30 Environment: Tomcat 5.5, JDK 1.4 Reporter: Rainer Rohloff An disabled Button/Link does not use the Disabled Icon ( *Disabled.gif - defined in the Theme) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
About the JVM bug with 2.2250738585072012e-00308
Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo
Re: About the JVM bug with 2.2250738585072012e-00308
txs 4 the review! But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. not abnormal but still moderately unlikely. I agree for a long term scenario. Basically the default should be to disable this workaround and to make it available via configuration. Btw, it seems that Oracle finally reacted and will hopefully ship a fixed JVM 1.6 soon (no help for Java5 users of course). The fix should also be done for 1.2, because many productive systems using it. +1 LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeil u...@schnurpfeil.de wrote: From: Udo Schnurpfeil u...@schnurpfeil.de Subject: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Development dev@myfaces.apache.org Date: Thursday, February 10, 2011, 10:59 AM Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo
Re: About the JVM bug with 2.2250738585072012e-00308
BTW: The hotfix from Oracle is for 1.4, 5.0 and 6.0. Regards Udo Am 10.02.11 12:06, schrieb Mark Struberg: txs 4 the review! But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. not abnormal but still moderately unlikely. I agree for a long term scenario. Basically the default should be to disable this workaround and to make it available via configuration. Btw, it seems that Oracle finally reacted and will hopefully ship a fixed JVM 1.6 soon (no help for Java5 users of course). The fix should also be done for 1.2, because many productive systems using it. +1 LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeilu...@schnurpfeil.de wrote: From: Udo Schnurpfeilu...@schnurpfeil.de Subject: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Developmentdev@myfaces.apache.org Date: Thursday, February 10, 2011, 10:59 AM Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo
Re: About the JVM bug with 2.2250738585072012e-00308
Udo, is there a link to their bug? pretty interesting that they now fix it for almost everything :) On Thu, Feb 10, 2011 at 1:14 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: BTW: The hotfix from Oracle is for 1.4, 5.0 and 6.0. Regards Udo Am 10.02.11 12:06, schrieb Mark Struberg: txs 4 the review! But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. not abnormal but still moderately unlikely. I agree for a long term scenario. Basically the default should be to disable this workaround and to make it available via configuration. Btw, it seems that Oracle finally reacted and will hopefully ship a fixed JVM 1.6 soon (no help for Java5 users of course). The fix should also be done for 1.2, because many productive systems using it. +1 LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeilu...@schnurpfeil.de wrote: From: Udo Schnurpfeilu...@schnurpfeil.de Subject: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Developmentdev@myfaces.apache.org Date: Thursday, February 10, 2011, 10:59 AM Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: About the JVM bug with 2.2250738585072012e-00308
but do they release 1.2 and 5.0 also to the public, or only to paying customers? LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeil u...@schnurpfeil.de wrote: From: Udo Schnurpfeil u...@schnurpfeil.de Subject: Re: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Development dev@myfaces.apache.org Date: Thursday, February 10, 2011, 12:14 PM BTW: The hotfix from Oracle is for 1.4, 5.0 and 6.0. Regards Udo Am 10.02.11 12:06, schrieb Mark Struberg: txs 4 the review! But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. not abnormal but still moderately unlikely. I agree for a long term scenario. Basically the default should be to disable this workaround and to make it available via configuration. Btw, it seems that Oracle finally reacted and will hopefully ship a fixed JVM 1.6 soon (no help for Java5 users of course). The fix should also be done for 1.2, because many productive systems using it. +1 LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeilu...@schnurpfeil.de wrote: From: Udo Schnurpfeilu...@schnurpfeil.de Subject: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Developmentdev@myfaces.apache.org Date: Thursday, February 10, 2011, 10:59 AM Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo
Re: About the JVM bug with 2.2250738585072012e-00308
http://www.oracle.com/technetwork/topics/security/alert-cve-2010-4476-305811.html LieGrue, strub --- On Thu, 2/10/11, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf mat...@apache.org Subject: Re: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Development dev@myfaces.apache.org Date: Thursday, February 10, 2011, 12:16 PM Udo, is there a link to their bug? pretty interesting that they now fix it for almost everything :) On Thu, Feb 10, 2011 at 1:14 PM, Udo Schnurpfeil u...@schnurpfeil.de wrote: BTW: The hotfix from Oracle is for 1.4, 5.0 and 6.0. Regards Udo Am 10.02.11 12:06, schrieb Mark Struberg: txs 4 the review! But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. not abnormal but still moderately unlikely. I agree for a long term scenario. Basically the default should be to disable this workaround and to make it available via configuration. Btw, it seems that Oracle finally reacted and will hopefully ship a fixed JVM 1.6 soon (no help for Java5 users of course). The fix should also be done for 1.2, because many productive systems using it. +1 LieGrue, strub --- On Thu, 2/10/11, Udo Schnurpfeilu...@schnurpfeil.de wrote: From: Udo Schnurpfeilu...@schnurpfeil.de Subject: About the JVM bug with 2.2250738585072012e-00308 To: MyFaces Developmentdev@myfaces.apache.org Date: Thursday, February 10, 2011, 10:59 AM Hi, I've some comments to the JVM bug for the bad number 2.2250738585072012e-00308 (https://issues.apache.org/jira/browse/MYFACES-3024) The problem occures for values which are very very low. But the hotfix also rejects numbers like 2.22507385850720120e-10 which is not so abnormal. Would it not be better, when the hotfix is configurable (be default turned on), so that the admin can switch it off, when the JVM bugfix is applied? The fix should also be done for 1.2, because many productive systems using it. What do you think? Regards Udo -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Maven3 ?
With a similar issue in one of my projects, related to the slightly different version range resolution with maven 2 and 3 I just came across this: https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.x https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.xYou can use that hack to do one thing if you have maven 3 or another if you have maven 2... Cheers, Bruno On 27 January 2011 15:15, Matthias Wessendorf mat...@apache.org wrote: mvn site works locally (I changed the site plugin version). Trinidad Tagdoc, JavaDoc, RAT, Findbugs = all work (at least locally on my Ubuntu box) -M On Thu, Jan 27, 2011 at 2:58 PM, Werner Punz werner.p...@gmail.com wrote: How is the entire reporting secion doing, the last time I did a deep check maven3 did not have the reporting anymore and the new external modules were under development. Werner Am 27.01.11 07:16, schrieb Matthias Wessendorf: Hi, what are folks thinking about using Maven3. I did some tests for Trinidad and Maven 3 yesterday ([1]). Things like the regular build and site generation is working fine. I am not (yet) 100% how our (Apache) Hudson build machine like Maven3 (I used 3.0.2). However we can simply test that. I wonder if folks would mind, if the Trinidad build (as a starter...) would be requiring Maven3.x, in the near future? Greetings, Matthias [1] https://issues.apache.org/jira/browse/TRINIDAD-2006 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Time for a new Trindiad Beta Release
Hey everyone, Now might be a good time for a new Trinidad 2.0 beta release. Does anyone have any issues that need to be addressed before I start this process? If not, I'll plan on starting the release process tomorrow. Thanks Scott O'Bryan
[TRINIDAD] Time for a new Trindiad Beta Release
Sorry about not adding the tag to this.. ;) On 02/10/2011 11:10 AM, Scott O'Bryan wrote: Hey everyone, Now might be a good time for a new Trinidad 2.0 beta release. Does anyone have any issues that need to be addressed before I start this process? If not, I'll plan on starting the release process tomorrow. Thanks Scott O'Bryan
Re: Time for a new Trindiad Beta Release
Fine with me! -M On Thu, Feb 10, 2011 at 7:10 PM, Scott O'Bryan darkar...@gmail.com wrote: Hey everyone, Now might be a good time for a new Trinidad 2.0 beta release. Does anyone have any issues that need to be addressed before I start this process? If not, I'll plan on starting the release process tomorrow. Thanks Scott O'Bryan -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [TRINIDAD] Time for a new Trindiad Beta Release
I'm all good. -- Blake Sullivan On 2/10/11 10:24 AM, Scott O'Bryan wrote: Sorry about not adding the tag to this.. ;) On 02/10/2011 11:10 AM, Scott O'Bryan wrote: Hey everyone, Now might be a good time for a new Trinidad 2.0 beta release. Does anyone have any issues that need to be addressed before I start this process? If not, I'll plan on starting the release process tomorrow. Thanks Scott O'Bryan
Re: [RESULT] [VOTE] Release Tobago 1.0.33
Hi, I've updated the Tobago Demo on http://irian.biz/tobago-example-demo/ to 1.0.33. (I've also applied the floating point patch for 2.2250738585072012e-308 from Oracle on the open JDK and it works fine.) Regards Udo Am 07.02.11 23:36, schrieb Bernd Bohmann: The vote has passed with the following results: +1 lofwyr (binding) weber(binding) bommel (binding) matzew(binding) werpu(binding) struberg I will proceed with the next steps. Regards Bernd On Mon, Feb 7, 2011 at 7:50 PM, Mark Strubergstrub...@yahoo.de wrote: +1 builds find, rat runs ok, checkstyles + pgp also LieGrue, strub --- On Mon, 2/7/11, Matthias Wessendorfmat...@apache.org wrote: From: Matthias Wessendorfmat...@apache.org Subject: Re: [VOTE] Release Tobago 1.0.33 To: MyFaces Developmentdev@myfaces.apache.org Date: Monday, February 7, 2011, 2:48 PM +1 On Mon, Feb 7, 2011 at 3:47 PM, Bernd Bohmannbernd.bohm...@atanion.com wrote: Here is my +1 On Mon, Feb 7, 2011 at 3:12 PM, Volker Weberv.we...@inexso.de wrote: Hi, +1 Regards, Volker 2011/2/5 Bernd Bohmannbernd.bohm...@atanion.com: Hello, I would like to release Tobago 1.0.33. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12315586 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-037 The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Hamburg | Amtsgericht Hamburg, HRB 84273 Geschäftsführer: Stefan Schulte, Michael Terschüren, Dirk Fangohr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Reopened: (TOMAHAWK-1389) TableSuggestAjax - security popup in IE7 when using SSL
[ https://issues.apache.org/jira/browse/TOMAHAWK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz reopened TOMAHAWK-1389: --- ok as it seems the, issue is in another codepart and as it seems the outerHTML = seems to resolve it, now the problem with outerHTML = simply is this approach of clearing the dom tree is not really well working either. I will merge the delete dom code from myfaces in which tackles the problem in a much cleaner way or i will only trigger outerHTML = for old ie browsers. Either way I have to reopen the issue. TableSuggestAjax - security popup in IE7 when using SSL --- Key: TOMAHAWK-1389 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1389 Project: MyFaces Tomahawk Issue Type: Bug Components: Alias Bean Affects Versions: 1.1.8 Environment: myfaces 1.2.5 tomahawk 1.1.8 sandbox 1.1.7 snapshot facelets 1.1.14 tomcat 6.16 Apache mod_jk 2 (issue also comes up without mod_jk) Reporter: Gerd Schaffer Assignee: Werner Punz Attachments: TOMAHAWK-1389.patch, dojo_patched.js A security popup comes up when using TableSuggestAjax in Internet Explorer 7 (IE7) when using SSL / HTTPS with the message: Warning: This page contains secure and non secure items ... Warnung: Diese Seite enthält sichere und nicht sichere Objekte ... TableSuggestAjax works in IE6, Mozilla, Safari and Google Chrome - just IE7 has this security-issue. what is going on in TableSuggestAjax component? Is there a possibility to fix this (with or without code change)? (telling IE7 not to report this errors (in ie-preferences) is not meant as fix) thank you in advance! -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Revision numbers in MANIFEST.MF file (was: Re: svn commit: r1069504 - in /myfaces/trinidad/trunk: trinidad-api/pom.xml trinidad-impl/pom.xml)
Hello Matthias, For a release the revision number is not needed. For a snapshot it might be helpful if someone reports a bug and it's not clear with revision was the base for the snapshot. Regards Bernd Am 10.02.2011 19:23 schrieb Matthias Wessendorf mat...@apache.org: Having the actual revision number inside of the manifest.mf file is nice. However, not sure if that is really needed for every build, therefore I commented it out. Perhaps this should be done only in the release profile ? What do you think ? -Matthias On Thu, Feb 10, 2011 at 7:05 PM, mat...@apache.org wrote: Author: matzew Date: Thu Feb 10 18:05:24 2011 New Revision: 1069504 URL: http://svn.apache.org/viewvc?rev=1069504view=rev Log: disabling the svn revision number plugin - should it be done only on release profile??? Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml myfaces/trinidad/trunk/trinidad-impl/pom.xml Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-api/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-api/pom.xml Thu Feb 10 18:05:24 2011 @@ -172,7 +172,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -190,7 +191,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Thu Feb 10 18:05:24 2011 @@ -211,7 +211,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -229,7 +230,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (EXTCDI-130) InstanceProducer not serializable
[ https://issues.apache.org/jira/browse/EXTCDI-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-130. - Resolution: Won't Fix that's a weld bug. as far as we know it will be fixed with weld 1.2. with glassfish 3.0.1 it just happens in case of session replication and in case of a shutdown. InstanceProducer not serializable - Key: EXTCDI-130 URL: https://issues.apache.org/jira/browse/EXTCDI-130 Project: MyFaces CODI Issue Type: Bug Reporter: Matthias Weßendorf Deploying a WAR file, which contains CoDI 0.9.2 to Glassfish 3.1 (RC2) I am getting a NotSerializableException -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993277#comment-12993277 ] Scott O'Bryan commented on MYFACES-3039: Ahhh yes. Mike, you're one hundred percent right. Pre-JSF 2.0 I don't think we delegated because there was no concept of an ExternalContextFactory. That was set up by the FacesContextFactory. Now, however, the ExternalContextFactory is the hook point for the container abstraction. Simply put the FacesContextFactory should not care what objects back the ExternalContext so long as the contracts are followed and, looking at the code above, it is unclear to me why the check is even there. I suspect that its there because FacesContext used to instantiate externalContext itself (and there clearly used to be a cast to the native objects).. So yeah, the FacesContext and Factory should be container agnostic for JSF 2.0. MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext Key: MYFACES-3039 URL: https://issues.apache.org/jira/browse/MYFACES-3039 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Michael Freedman JSF 2.0 improved the definition/handling of the instantiation of the FacesContext allowing non-servlet environments to wrap the base/core impl. This was done because most of the FacesContext apis are inherently runtime environment neutral -- allowing the portlet bridge to not have to duplicate/reimplement and maybe get wrong base core function. Unfortunately MyFaces doesn't conform to this change and hence the Portlet Bridge can't run in the MyFaces environment. Basically the bridge expects to be able to delegate from its FacesContextFactoryImpl.getFacesContext and then wrap the returned FacesContext with its own. This requires the underlying core impl to be runtime (servlet/portlet) neutral during the creation process. The bridge will wrap the FacesContext and supply its own ExternalContext such that any servlet dependent impl in the core FacesContext/ExternalContext will be hidden by overrides. FYI ... until this is addressed I can't begin any testing of the bridge on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-1958) Client tr:numberConverter with type=currency incorrectly handles arabic locale for positive values
[
https://issues.apache.org/jira/browse/TRINIDAD-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabrielle Crawford resolved TRINIDAD-1958.
--
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Assignee: Gabrielle Crawford
Client tr:numberConverter with type=currency incorrectly handles arabic
locale for positive values
Key: TRINIDAD-1958
URL: https://issues.apache.org/jira/browse/TRINIDAD-1958
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.13-core
Reporter: Yee-Wah Lee
Assignee: Gabrielle Crawford
Priority: Minor
Fix For: 2.0.0-beta-2
1. Use the following jspx, binding the value of the inputText to a positive
integer.
tr:inputText label=InputText Arabic value=#{clientValidation.integer}
autoSubmit=true
tr:convertNumber type=currency locale=ar_SA/
/tr:inputText
tr:outputText value=Value submitted is
#{clientValidation.integer}/
2. Run the jspx, it displays something like:
2ر.س. 0
3. Modify just the numerical portion of the text and tab off: Get an
Incorrect Format error
Enter a currency in the same format as this example: ر.س. 10,250
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [TRINIDAD] Time for a new Trindiad Beta Release
Gang - I was somewhat hoping to get a fix in for this issue soon: https://issues.apache.org/jira/browse/TRINIDAD-2030 Unfortunately, I am out of the office today/tomorrow. Any chance we can hold off on firing up the release just a bit to give me a chance to get this in? Andy
Re: Issue 2995 - Leo please read
Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. regards, Leonardo Uribe
[jira] Resolved: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3039. - Resolution: Fixed Fix Version/s: 2.0.5-SNAPSHOT Assignee: Leonardo Uribe Ok, now I understand, it is more simple than it seems to be. The check is there just by historical reasons, so we can just comment it and prevent throw the exception. The current FacesContext implementation should work without problem in portlet case. MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext Key: MYFACES-3039 URL: https://issues.apache.org/jira/browse/MYFACES-3039 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Michael Freedman Assignee: Leonardo Uribe Fix For: 2.0.5-SNAPSHOT JSF 2.0 improved the definition/handling of the instantiation of the FacesContext allowing non-servlet environments to wrap the base/core impl. This was done because most of the FacesContext apis are inherently runtime environment neutral -- allowing the portlet bridge to not have to duplicate/reimplement and maybe get wrong base core function. Unfortunately MyFaces doesn't conform to this change and hence the Portlet Bridge can't run in the MyFaces environment. Basically the bridge expects to be able to delegate from its FacesContextFactoryImpl.getFacesContext and then wrap the returned FacesContext with its own. This requires the underlying core impl to be runtime (servlet/portlet) neutral during the creation process. The bridge will wrap the FacesContext and supply its own ExternalContext such that any servlet dependent impl in the core FacesContext/ExternalContext will be hidden by overrides. FYI ... until this is addressed I can't begin any testing of the bridge on MyFaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
