Re: JBoss and MyFaces ....
On Fri, Oct 15, 2010 at 2:47 AM, ssilv...@redhat.com wrote: Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] What about MyFaces 1.2 ? :) Just to be clear, it's AS6 SNAPSHOT, not AS5. All Lincoln's fault! :)) The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ Interesting timing, I think I will give it a shot, since I need to do some work/comparison on WebProfile Servers ;) I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Thanks for the integration work, Stan. Big thanks to Leo for driving this. -Matthias Stan Quoting Matthias Wessendorf mat...@apache.org: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. Werner
[jira] Commented: (TRINIDAD-119) InputDate popup crashes when using extension mapping
[ https://issues.apache.org/jira/browse/TRINIDAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921275#action_12921275 ] Tomas Havelka commented on TRINIDAD-119: Is there a plan to solve this issue in the Trinidad's next release? I can confirm the same problem with 1.2.13 release of Trinidad. It's a strange behavior for me to be forced to use /faces/ mapping for Facelets pages, which has very well known extension .xhtml. The problem can be quickly solved by rewriting the GenericEntry scriplet to support javax.faces.DEFAULT_SUFFIX context parameter, I think. InputDate popup crashes when using extension mapping Key: TRINIDAD-119 URL: https://issues.apache.org/jira/browse/TRINIDAD-119 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.1-core Environment: Apache Tomcat 6.0.13, JDK 1.6.02, Facelets 1.1.11, Trinidad 1.2.1, MyFaces 1.2.0, Ajax4jsf 1.0.6 Reporter: Jan-Kees van Andel Attachments: MyFacesBugFixFilter.java, MyFacesBugFixFilter.java, TRINIDAD-119-trinidad-impl.patch If I use extension mapping (*.faces), my inputDate component crashes with a 404 when I click on the button. The message is: The requested resource (/mblf/__ADFv__) is not available. When using prefix mapping (/faces/), everything works fine. The URL it references is: http://localhost:8080/mblf/faces/__ADFv__?_t=fred_red=cdvalue=118505880loc=en -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (TRINIDAD-744) Update translated message files
[ https://issues.apache.org/jira/browse/TRINIDAD-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-744. - Resolution: Fixed Fix Version/s: 2.0.0.4-core 1.2.15-core Update translated message files --- Key: TRINIDAD-744 URL: https://issues.apache.org/jira/browse/TRINIDAD-744 Project: MyFaces Trinidad Issue Type: Bug Reporter: Bud Osterberg Assignee: Matthias Weßendorf Fix For: 1.2.14-core , 2.0.0.3-core, 1.2.15-core , 2.0.0.4-core Attachments: trinidad-translations.xml, trinslations-090917.tar.gz, trinslations-1.2.12.3-101004.tar.gz, trinslations-trunk-101004.tar.gz, trinslations080326.zip, trinslations080326.zip.md5, trinslations080326.zip.sha1, trinslations080702.zip, trinslations090825.tar.gz, trinslations100414_1.2.12.3.tar.gz, trinslations_090112.jar, trinslations_090421.tar.gz, trinslations_090701.jar, trinslations_1.2.12.1_091009.tar.gz, trinslations_1.2.12.1_091207.tar.gz, trinslations_1.2.12.2_091009.tar.gz, trinslations_1.2.12.2_091022.tar.gz, trinslations_1.2.12.2_100329.zip, trinslations_1.2.12.3_100823.tar.gz, trinslations_trunk_100524.tar.gz, trinslations_trunk_100804.tar.gz Latest versions of the message files (LoggerBundle, MessageBundle, and CoreBundle) need translations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
Am 15.10.10 10:19, schrieb Matthias Wessendorf: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Btw. it is getting off topic, is it just me - but I have the impression that we get significantly less bugreports on the core in since 2.0.2 is out. Werner
Re: JBoss and MyFaces ....
I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2942) Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2 -- Key: MYFACES-2942 URL: https://issues.apache.org/jira/browse/MYFACES-2942 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2, 2.0.1 Environment: JBOSS AS Reporter: Werner Punz Priority: Critical Stan Silvert from JBoss reports: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner
Re: JBoss and MyFaces ....
Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner
Re: JBoss and MyFaces ....
Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner
[jira] Commented: (MYFACES-2942) Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
[ https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921323#action_12921323 ] Bruno Aranda commented on MYFACES-2942: --- Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2 -- Key: MYFACES-2942 URL: https://issues.apache.org/jira/browse/MYFACES-2942 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1, 2.0.2 Environment: JBOSS AS Reporter: Werner Punz Priority: Critical Stan Silvert from JBoss reports: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: JBoss and MyFaces ....
The permgen error usually is an overload of classes which means if a class is loaded and loaded and loaded again. Maybe we have a problem in our way way instantiate classes dynamically so that they constantly are reregistered in the classloader and never dropped. Just a wild guess here. Werner Am 15.10.10 14:32, schrieb Jakob Korherr: The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 Bruno Arandabrunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? Bruno On 15 October 2010 13:12,ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punzwerner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner
Re: JBoss and MyFaces ....
Quoting Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? That's exactly the kind of leak that Mojarra had. The other leak I've been seeing in code lately is where you use a WeakHashMap and the value contains the key. Your key/value will never be removed in that case. See the WeakHashMap javadoc if you aren't familiar with that leak. Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner
Re: JBoss and MyFaces ....
Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Quoting Jakob Korherr jakob.korh...@gmail.com: The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. I disagree. That could easily be the cause as was the case with Mojarra. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: JBoss and MyFaces ....
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punz werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15 ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punz werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
jetty-8.0.0.M1
Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ? Looks like I (currently) have to add this: listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: jetty-8.0.0.M1
I have not used it, but if this is a problem with Servlet 3.0, we could use the MyFacesContainerInitializer (from implee6) to automatically add the StartupServletContextListener. Regards, Jakob 2010/10/15 Matthias Wessendorf mat...@apache.org: Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ? Looks like I (currently) have to add this: listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: jetty-8.0.0.M1
No I haven't. But it looks like Jetty is not looking in the TLD files for the context listeners. Sent from my iPhone On Oct 15, 2010, at 6:59 AM, Matthias Wessendorf mat...@apache.org wrote: Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ? Looks like I (currently) have to add this: listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: jetty-8.0.0.M1
This sort of thing has been an issue in the past with jetty. Sometimes it has been intentional, and you have to enable a configuration parameter to make it work. On Fri, Oct 15, 2010 at 9:02 AM, Scott O'Bryan darkar...@gmail.com wrote: No I haven't. But it looks like Jetty is not looking in the TLD files for the context listeners. Sent from my iPhone On Oct 15, 2010, at 6:59 AM, Matthias Wessendorf mat...@apache.org wrote: Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ? Looks like I (currently) have to add this: listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2942) Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
[ https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921373#action_12921373 ] Martin Kočí commented on MYFACES-2942: -- after 10 deploy-undeploy of same app at tomcat 6 (after each redeploy I did one request to a view) 1 instance of RuntimeConfig (keeps live instances of NavigationCase and NavigationRule and many others) 362 instances of org.apache.myfaces.view.facelets.tag.MetadataTargetImpl - for those Memory Analyzer (http://www.eclipse.org/mat/) shows that immediate dominator is org.apache.catalina.loader.WebappClassLoader. RuntimeConfig is not GCed but next deploy replaces instance - only one instance remain. MetadataTargetImpl is another story - number of instances grows after every redeploy. Each 39 instances of MetadataTargetImpl are loaded with different WebappClassLoader instance (17 live instances of WebappClassLoader in time of snapshot). It looks like a cumulative issue: something (probably RuntimeConfig) prevents WebappClassLoader instance to be GCed. Next deploy create new WebappClassLoader which loads classes again and consumes perm gen space. Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2 -- Key: MYFACES-2942 URL: https://issues.apache.org/jira/browse/MYFACES-2942 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1, 2.0.2 Environment: JBOSS AS Reporter: Werner Punz Priority: Critical Stan Silvert from JBoss reports: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2942) Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
[ https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921377#action_12921377 ] Jakob Korherr commented on MYFACES-2942: Thanks a lot for this info, Martin! I'll try to fix the issue with RuntimeConfig, then we'll see if the MetadataTargetImpl problem still exists.. Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2 -- Key: MYFACES-2942 URL: https://issues.apache.org/jira/browse/MYFACES-2942 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1, 2.0.2 Environment: JBOSS AS Reporter: Werner Punz Priority: Critical Stan Silvert from JBoss reports: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-946) tr:panelPopup incorrect placement in IE7 and IE6 with long pages
[ https://issues.apache.org/jira/browse/TRINIDAD-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921400#action_12921400 ] Andrew Robinson commented on TRINIDAD-946: -- You will need to provide a test case as each page may be different. For example, CSS that you are using may be causing it to break. tr:panelPopup incorrect placement in IE7 and IE6 with long pages Key: TRINIDAD-946 URL: https://issues.apache.org/jira/browse/TRINIDAD-946 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.5-core, 1.0.6-core Environment: Server: Windows 2003, Tomcat 5.5.25, JDK 1.5.0_14, Myfaces 1.1.5, Trinidad 1.0.6, Trinidad 1.0.5 Client: IE7, IE6, Firefox 2.0.0.12 Reporter: Jed Smallwood In IE7 and IE6 the placement of a relative positioned popup is always within the initial visible page section of the browser window as opposed to anywhere on the page. For example, my table has 50 rows. On the initial page load 12 rows are visible with my browser size. My observation is that the popup will not render below the 12th row even when the page has been scrolled down to row 50. Clicking on the popup trigger in the 50th row will render the correct popup on top of the 12th row as opposed to the 50th row. Viewing the same page in Firefox 2.0.0.12, all popups are rendered in the correct positions. After posting this to the myfaces user mailing list, Andrew Robinson responded with the following: I haven't had the time to look into some positioning problems with the popup, but there are many bugs in IE with regards to component location calculations. Open a bug We will need to come up with a solution where there is IE and Firefox specific JS code using bounding box code instead of attempting to use the w3c implementations which are not properly implemented by most browsers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Thanks for the info, Blake! Leo, please take a look at my comment + patch on MYFACES-2942. I did exactly what you just said and I fully agree with you! If there are no objections to that patch, I'll commit it tomorrow! Regards, Jakob 2010/10/15 Leonardo Uribe lu4...@gmail.com: Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: JBoss and MyFaces ....
I completely agree that the best solution is to get rid of ThreadLocals that we don't need. -- Blake Sullivan On 10/15/10 11:26 AM, Leonardo Uribe wrote: Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com mailto:blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com mailto:ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com mailto:ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Stan Quoting Matthias Wessendorfmat...@apache.org mailto:mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1920) DateTimeRangevalidator fails across multiple timezones
[ https://issues.apache.org/jira/browse/TRINIDAD-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-1920: -- Resolution: Fixed Fix Version/s: 1.2.15-core 2.0.0.3-core Status: Resolved (was: Patch Available) DateTimeRangevalidator fails across multiple timezones -- Key: TRINIDAD-1920 URL: https://issues.apache.org/jira/browse/TRINIDAD-1920 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor Fix For: 2.0.0.3-core, 1.2.15-core Attachments: 12123_1920.diff, 12x_1920.diff, trin12_1920.diff This is a regression from TRINIDAD-1818 where the DateTimeRangeValidator was created with Date/ms. https://issues.apache.org/jira/browse/TRINIDAD-1818 Because the Javascript client is not able to correctly calculate timezone offsets for different timezones, it should take the min/max as a String and convert that into a Date. The converted value would have the same offset as the value, and validation would be all on objects with the same timezone offset. Fix is to revert to using Strings, but also pass the date as an ISO string when the converter pattern is insufficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1939) SessionChangeManager should restore attribute lock after session failover
[
https://issues.apache.org/jira/browse/TRINIDAD-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1939.
---
Resolution: Fixed
Fix Version/s: 1.2.15-core
2.0.0.3-core
SessionChangeManager should restore attribute lock after session failover
-
Key: TRINIDAD-1939
URL: https://issues.apache.org/jira/browse/TRINIDAD-1939
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.12-core
Reporter: Yuan Gao
Fix For: 2.0.0.3-core, 1.2.15-core
Attachments: cm-serialproxy.patch.1.2.12.3,
cm-serialproxy.patch.1.2.x, cm-serialproxy.patch.trunk
The issue is in SessionChangeManager, we have an attribute lock, as this:
private transient final Object _attrRebuildLock = new Object();
And we synchronize on this object when we want to modify the changes arrays.
When failover happens, this field becomes null. And future synchronization
will fail since it's null. The fix is to implement the readObject() method,
and re-initialize the _attrRebuildLock field to be new Object();
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException
{
in.defaultReadObject();
_attrRebuildLock = new Object();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
