Re: svn commit: r903822 [15/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/ trinidad-components-showcase/src/main/ trinidad-com
please revert this!!!
it does contain GPL code...
Guys! we should KNOW that this is a NO-GO !!!
On Wed, Jan 27, 2010 at 9:37 PM, ckor...@apache.org wrote:
Added:
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js?rev=903822view=auto
==
---
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js
(added)
+++
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js
Wed Jan 27 20:37:29 2010
@@ -0,0 +1,35 @@
+/**
+ * SyntaxHighlighter
+ * http://alexgorbatchev.com/
+ *
+ * SyntaxHighlighter is donationware. If you are using it, please donate.
+ * http://alexgorbatchev.com/wiki/SyntaxHighlighter:Donate
+ *
+ * @version
+ * 2.1.364 (October 15 2009)
+ *
+ * @copyright
+ * Copyright (C) 2004-2009 Alex Gorbatchev.
+ *
+ * @license
+ * This file is part of SyntaxHighlighter.
+ *
+ * SyntaxHighlighter is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * SyntaxHighlighter is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with SyntaxHighlighter. If not, see
http://www.gnu.org/copyleft/lesser.html.
+ */
+SyntaxHighlighter.brushes.Plain = function()
+{
+};
+
+SyntaxHighlighter.brushes.Plain.prototype = new
SyntaxHighlighter.Highlighter();
+SyntaxHighlighter.brushes.Plain.aliases = ['text', 'plain'];
Propchange:
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js
--
svn:eol-style = native
Propchange:
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPlain.js
--
svn:mime-type = text/plain
Added:
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPowerShell.js
URL:
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPowerShell.js?rev=903822view=auto
==
---
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPowerShell.js
(added)
+++
myfaces/trinidad/trunk/trinidad-examples/trinidad-components-showcase/src/main/webapp/js/shBrushPowerShell.js
Wed Jan 27 20:37:29 2010
@@ -0,0 +1,76 @@
+/**
+ * SyntaxHighlighter
+ * http://alexgorbatchev.com/
+ *
+ * SyntaxHighlighter is donationware. If you are using it, please donate.
+ * http://alexgorbatchev.com/wiki/SyntaxHighlighter:Donate
+ *
+ * @version
+ * 2.1.364 (October 15 2009)
+ *
+ * @copyright
+ * Copyright (C) 2004-2009 Alex Gorbatchev.
+ *
+ * @license
+ * This file is part of SyntaxHighlighter.
+ *
+ * SyntaxHighlighter is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * SyntaxHighlighter is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with SyntaxHighlighter. If not, see
http://www.gnu.org/copyleft/lesser.html.
+ */
+SyntaxHighlighter.brushes.PowerShell = function()
+{
+ // Contributes by B.v.Zanten, Getronics
+ // http://confluence.atlassian.com/display/CONFEXT/New+Code+Macro
+
+ var keywords = 'Add-Content Add-History Add-Member Add-PSSnapin
Clear(-Content)? Clear-Item ' +
+ 'Clear-ItemProperty Clear-Variable
Compare-Object ConvertFrom-SecureString Convert-Path ' +
+ 'ConvertTo-Html ConvertTo-SecureString
Copy(-Item)? Copy-ItemProperty Export-Alias ' +
+ 'Export-Clixml Export-Console Export-Csv
ForEach(-Object)? Format-Custom Format-List ' +
+
Re: [OFFTOPIC] JSFDays 2010 Vienna
I hope to meet some of you there! regards Michael Am 26.01.2010 10:25, schrieb Gerhard Petracek: Hi all, we'd like to invite you to come to a JSF conference in Vienna, Austria from 23rd-25th of February. The program is packed with the latest and greatest information about JSF 2.0 and the new versions of the major component libraries as well as extensions. It will be worthwhile for you as a JSF developer to hear what this new version of JSF has to offer. In addition to the JSF track, there will also be a general Java EE track where the important new developments in the Java EE space will be covered. Additionally, the third day hosts a series of workshops on such interesting topics as: - Collaboration with Ajax Push, ICEfaces 2, and JSF 2 - RichFaces 4 with JSF 2 - The Java Memory Model - Real World Java EE (Patterns) - Rethinking Best Practices - Developing loosely coupled services - Hands on with the Portlet Bridge - Go Fullstack: JSF, Spring, JPA perfectly linked Here is the link: http://conference.irian.at - click on “Registration”. Attendees will pay a very small conference fee - 360,- Euro (including 20% VAT). The third day - the workshop day - will be charged separately. The attendance fee for the workshop day is 600,- Euro (including 20% VAT) per person. There will be a supporting program alongside the conference - so you will (additionally to learning about JSF and improving your JSF knowledge) have a good chance of getting to know Vienna and its surroundings. So far, there have been a lot registrations - so this conference is definitely going to be a meeting point for everyone interested in JSF! Regards, Gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2508) Miscellaneous CTS fixes
[ https://issues.apache.org/jira/browse/MYFACES-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805885#action_12805885 ] Curtiss Howard commented on MYFACES-2508: - Fixed CTS testcase jsf/api/javax_faces/convert/enumconverter/URLClient_enumConverterGetAsObjectCETest: ConverterException was assuming a non-null FacesMessage was passed to it. As far as I can tell, that's only the case when a completely unsupported locale is present. Miscellaneous CTS fixes --- Key: MYFACES-2508 URL: https://issues.apache.org/jira/browse/MYFACES-2508 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Curtiss Howard This issue will be used to fix problems identified by CTS testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2508) Miscellaneous CTS fixes
[ https://issues.apache.org/jira/browse/MYFACES-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805886#action_12805886 ] Curtiss Howard commented on MYFACES-2508: - Fixed CTS testcase jsf/api/javax_faces/component/uiselectitems/URLClient_stateHolderSaveStateNPETest: StateHolder Javadocs indicate that saveState() and restoreState() need to throw NPEs if the args are null. Instead of fixing EVERY StateHolder implementing class, I fixed the one that is directly user-accessible: UIComponentBase. Miscellaneous CTS fixes --- Key: MYFACES-2508 URL: https://issues.apache.org/jira/browse/MYFACES-2508 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Curtiss Howard This issue will be used to fix problems identified by CTS testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSoc] Google Summer of Code Idea
Hi there, I'm a student in my last semester and highly interested in going in for the GSOC this year. However, I'm able to afford only 15 hours a week (approx.). Would it be a good idea to apply for this project unter these time limitation? I really don't have a clue about the required effort. I would appreciate an advice. Cheers, Ingo 2010/1/27 Matthias Wessendorf mat...@apache.org no hurry! :-) Take it easy ;-) Thanks! Matthias On Wed, Jan 27, 2010 at 10:41 AM, Ali Ok al...@aliok.com.tr wrote: Hi Matthias, Thanks for your support. I think this GSOC will be cool:) Since this will be a seperate project, I will start modifiying my local Tomahawk code-base, and inspecting how it works, right away. About GAE, I've started preparing the document yesterday, but couldn't finished. I will send the APT document, and a tutorial explaining how to set up a Eclipse project, this night for sure. Best Regards, Ali On Wed, Jan 27, 2010 at 11:25 AM, Matthias Wessendorf mat...@apache.org wrote: Hey Ali, the Google Summer of code has been announced (see my other email). Regarding this idea on HTML5 related stuff, I would like to sign as a mentor for it. @GAE: I saw your path; Jakob did a quick review. So, I hope we can commit that soon. Some more documentation, e.g. a guide or a tutorial would be nice :-) -Matthias On Wed, Jan 20, 2010 at 8:34 PM, Ali Ok al...@aliok.com.tr wrote: Hi all, I sent a couple of mails about MyFaces on Google App Engine GSOC proposal. But after some progress and a conversation with Matthias, I realized that it is too small for GSOC. And I am willing to implement HTML5 Renderkit. Meanwhile, I will work on GAE support in parallel. I will post my patch to JIRA after some -more- tests. Regards, Ali On Wed, Jan 6, 2010 at 11:52 PM, Gerhard Petracek gerhard.petra...@gmail.com 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/1/6 Matthias Wessendorf mat...@apache.org as the mentioned behavior support already said, I'd like to see this ONLY for JSF2.0 (MyFaces 2.0) -Matze On Wed, Jan 6, 2010 at 8:35 AM, Matthias Wessendorf mat...@apache.org wrote: Hi guys, running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. What do folks think about that? -- 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-1838) javax.crypto.BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/MYFACES-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805912#action_12805912 ] Michal Borowiecki commented on MYFACES-1838: We added org.apache.myfaces.SECRET context-param but we are still getting this exception after redeployment. myfaces 1.2.8, default algorithm, secret size of 8, base64 encoded using StateUtils, as described in http://wiki.apache.org/myfaces/Secure_Your_Application Any ideas? javax.crypto.BadPaddingException: Given final block not properly padded --- Key: MYFACES-1838 URL: https://issues.apache.org/jira/browse/MYFACES-1838 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Guy Bashan Attachments: MYFACES-1838.patch I keep getting this exception from time to time when moving between pages: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:373) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:184) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:136) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:289) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:505) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.vdo.admin.model.persistence.OpenSessionInViewFilterIC.doFilterInternal(OpenSessionInViewFilterIC.java:155) at com.vdo.admin.model.persistence.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369) ... 30 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1838) javax.crypto.BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/MYFACES-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805914#action_12805914 ] Michael Heinen commented on MYFACES-1838: - I had to turn it off (org.apache.myfaces.USE_ENCRYPTION=false) because this exception occurred randomly during jMeter performance tests. I could not see any pattern, sometimes the requests were fine and sometimes this exception occurs. javax.crypto.BadPaddingException: Given final block not properly padded --- Key: MYFACES-1838 URL: https://issues.apache.org/jira/browse/MYFACES-1838 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Guy Bashan Attachments: MYFACES-1838.patch I keep getting this exception from time to time when moving between pages: javax.faces.FacesException: javax.crypto.BadPaddingException: Given final block not properly padded at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:373) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:411) at org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:291) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:240) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:184) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlResponseStateManager.java:136) at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:289) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:505) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:85) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.vdo.admin.model.persistence.OpenSessionInViewFilterIC.doFilterInternal(OpenSessionInViewFilterIC.java:155) at com.vdo.admin.model.persistence.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:61) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.apache.myfaces.shared_impl.util.StateUtils.symmetric(StateUtils.java:369) ... 30 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Abwesenheitsnotiz: [jira] Commented: (MYFACES-1838) javax.crypto.BadPaddingException: Given final block not properly padded
In der Zeit vom 21.12.2009 bis 31.12.2009 bin ich nicht im Hause. Ihre Nachricht wird nicht automatisch weitergeleitet. Mit freundlichen Grüßen, Roland Schaal
Re: READ: New Trinidad demo contains GPL code (was: Fwd: svn commit: r903822 [1/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/
Hi catalin, The apache license and the gnu public license are not compatible from the asf side. It would be safe to remove the gpl code. Regards Bernd 28.01.2010 13:52 schrieb am Catalin Kormos catalin.kor...@gmail.com: Hi Matthias, This JS library SyntaxHighlighter is used to format code, and its license is GNU either version 3 or later: SyntaxHighlighter is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The apache 2.0 license seems to be compatible with it as shown here: http://www.apache.org/foundation/licence-FAQ.html#GPL Based on this I was thinking there is no issue with this, if I was wrong we will get rid of commited code which requires that GNU license. So it's for sure a no go? thanks, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: As far as I see it this is only some... -- Codebeat www.codebeat.ro
Re: READ: New Trinidad demo contains GPL code (was: Fwd: svn commit: r903822 [1/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/
Hi Bernd, Ok, the problematic code will be removed asap. There is still an alternate approach there, which was used first, formatting source code with https://jhighlight.dev.java.net/. This can easily replace the JS based formatting. Do you see any issues with using jhighlight? we don't distribute any code of it, just have a dependency to it. Sorry for any inconvenience. regards, Catalin On 1/28/10, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hi catalin, The apache license and the gnu public license are not compatible from the asf side. It would be safe to remove the gpl code. Regards Bernd 28.01.2010 13:52 schrieb am Catalin Kormos catalin.kor...@gmail.com: Hi Matthias, This JS library SyntaxHighlighter is used to format code, and its license is GNU either version 3 or later: SyntaxHighlighter is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The apache 2.0 license seems to be compatible with it as shown here: http://www.apache.org/foundation/licence-FAQ.html#GPL Based on this I was thinking there is no issue with this, if I was wrong we will get rid of commited code which requires that GNU license. So it's for sure a no go? thanks, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: As far as I see it this is only some... -- Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro
Re: READ: New Trinidad demo contains GPL code (was: Fwd: svn commit: r903822 [1/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/
Hey Catalin, CDDL may/can work: http://www.apache.org/legal/3party.html GPL3 is NOT compatible. However, projects that are licensed under GPL3 can actually now include Apache2 licensed software; That is the reason why *they* state GPL3 is compatible. See here, no the no-go section. http://www.apache.org/legal/resolved.html#category-x Some more info on Apache2 / GPL3: http://www.apache.org/licenses/GPL-compatibility.html Snip: *However, GPLv3 software cannot be included in Apache projects.* And it also explains implicit issues, that in worst case the Apache software (e.g. the demo) would have to be released under GPL3, which is a no-go = of course -Matthias On Thu, Jan 28, 2010 at 2:44 PM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Bernd, Ok, the problematic code will be removed asap. There is still an alternate approach there, which was used first, formatting source code with https://jhighlight.dev.java.net/. This can easily replace the JS based formatting. Do you see any issues with using jhighlight? we don't distribute any code of it, just have a dependency to it. Sorry for any inconvenience. regards, Catalin On 1/28/10, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hi catalin, The apache license and the gnu public license are not compatible from the asf side. It would be safe to remove the gpl code. Regards Bernd 28.01.2010 13:52 schrieb am Catalin Kormos catalin.kor...@gmail.com: Hi Matthias, This JS library SyntaxHighlighter is used to format code, and its license is GNU either version 3 or later: SyntaxHighlighter is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The apache 2.0 license seems to be compatible with it as shown here: http://www.apache.org/foundation/licence-FAQ.html#GPL Based on this I was thinking there is no issue with this, if I was wrong we will get rid of commited code which requires that GNU license. So it's for sure a no go? thanks, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: As far as I see it this is only some... -- Codebeat www.codebeat.ro -- Codebeat www.codebeat.ro -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2515) Archetype for MyFaces 2.0 hello world app
[ https://issues.apache.org/jira/browse/MYFACES-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805933#action_12805933 ] Michael Kurz commented on MYFACES-2515: --- is there no mail sent to the dev list for attaching a file? Anyway, I provided the MyFaces 2 CDI/OWB archetype. Archetype for MyFaces 2.0 hello world app - Key: MYFACES-2515 URL: https://issues.apache.org/jira/browse/MYFACES-2515 Project: MyFaces Core Issue Type: New Feature Reporter: Michael Kurz Attachments: MYFACES-2515-2.patch, MYFACES-2515.patch I created an archetype for a MyFaces 2.0 hello world app. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: READ: New Trinidad demo contains GPL code (was: Fwd: svn commit: r903822 [1/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/
Hey Matthias, All clear, thanks a lot for the clarifications, I might have went a bit too fast over the compatibility of licenses when I checked it out. regards, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, CDDL may/can work: http://www.apache.org/legal/3party.html GPL3 is NOT compatible. However, projects that are licensed under GPL3 can actually now include Apache2 licensed software; That is the reason why *they* state GPL3 is compatible. See here, no the no-go section. http://www.apache.org/legal/resolved.html#category-x Some more info on Apache2 / GPL3: http://www.apache.org/licenses/GPL-compatibility.html Snip: *However, GPLv3 software cannot be included in Apache projects.* And it also explains implicit issues, that in worst case the Apache software (e.g. the demo) would have to be released under GPL3, which is a no-go = of course -Matthias On Thu, Jan 28, 2010 at 2:44 PM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Bernd, Ok, the problematic code will be removed asap. There is still an alternate approach there, which was used first, formatting source code with https://jhighlight.dev.java.net/. This can easily replace the JS based formatting. Do you see any issues with using jhighlight? we don't distribute any code of it, just have a dependency to it. Sorry for any inconvenience. regards, Catalin On 1/28/10, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hi catalin, The apache license and the gnu public license are not compatible from the asf side. It would be safe to remove the gpl code. Regards Bernd 28.01.2010 13:52 schrieb am Catalin Kormos catalin.kor...@gmail.com: Hi Matthias, This JS library SyntaxHighlighter is used to format code, and its license is GNU either version 3 or later: SyntaxHighlighter is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The apache 2.0 license seems to be compatible with it as shown here: http://www.apache.org/foundation/licence-FAQ.html#GPL Based on this I was thinking there is no issue with this, if I was wrong we will get rid of commited code which requires that GNU license. So it's for sure a no go? thanks, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: As far as I see it this is only some... -- Codebeat www.codebeat.ro -- 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: READ: New Trinidad demo contains GPL code (was: Fwd: svn commit: r903822 [1/17] - in /myfaces/trinidad/trunk/trinidad-examples: ./ trinidad-components-showcase/ trinidad-components-showcase/src/
Hey Catalin, not a big deal. Honestly the licensing question is a not trivial drama :-) -M On Thu, Jan 28, 2010 at 3:49 PM, Catalin Kormos catalin.kor...@gmail.com wrote: Hey Matthias, All clear, thanks a lot for the clarifications, I might have went a bit too fast over the compatibility of licenses when I checked it out. regards, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: Hey Catalin, CDDL may/can work: http://www.apache.org/legal/3party.html GPL3 is NOT compatible. However, projects that are licensed under GPL3 can actually now include Apache2 licensed software; That is the reason why *they* state GPL3 is compatible. See here, no the no-go section. http://www.apache.org/legal/resolved.html#category-x Some more info on Apache2 / GPL3: http://www.apache.org/licenses/GPL-compatibility.html Snip: *However, GPLv3 software cannot be included in Apache projects.* And it also explains implicit issues, that in worst case the Apache software (e.g. the demo) would have to be released under GPL3, which is a no-go = of course -Matthias On Thu, Jan 28, 2010 at 2:44 PM, Catalin Kormos catalin.kor...@gmail.com wrote: Hi Bernd, Ok, the problematic code will be removed asap. There is still an alternate approach there, which was used first, formatting source code with https://jhighlight.dev.java.net/. This can easily replace the JS based formatting. Do you see any issues with using jhighlight? we don't distribute any code of it, just have a dependency to it. Sorry for any inconvenience. regards, Catalin On 1/28/10, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Hi catalin, The apache license and the gnu public license are not compatible from the asf side. It would be safe to remove the gpl code. Regards Bernd 28.01.2010 13:52 schrieb am Catalin Kormos catalin.kor...@gmail.com: Hi Matthias, This JS library SyntaxHighlighter is used to format code, and its license is GNU either version 3 or later: SyntaxHighlighter is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The apache 2.0 license seems to be compatible with it as shown here: http://www.apache.org/foundation/licence-FAQ.html#GPL Based on this I was thinking there is no issue with this, if I was wrong we will get rid of commited code which requires that GNU license. So it's for sure a no go? thanks, Catalin On 1/28/10, Matthias Wessendorf mat...@apache.org wrote: As far as I see it this is only some... -- Codebeat www.codebeat.ro -- 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
[jira] Commented: (TRINIDAD-1697) New Trinidad Components Showcase demo application
[ https://issues.apache.org/jira/browse/TRINIDAD-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806006#action_12806006 ] Maria Kaval commented on TRINIDAD-1697: --- Thanks for putting this together. Who can we contact to get this version of the demo hosted live at http://www.irian.at/trinidad-demo/faces/index.jspx? New Trinidad Components Showcase demo application - Key: TRINIDAD-1697 URL: https://issues.apache.org/jira/browse/TRINIDAD-1697 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.14-core Reporter: Cosmin Martinconi Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: trinidad-components-showcase.zip A new and improved Trinidad components showcase demo application: - the demo is working only with facelets (there is no jsp version) - we tried to build it so it can be searched online also, currently tried with Google Custom Search, but this didn't work out so smoothly so far. - in general, it replicates the examples available already for Trinidad in the existing demo, in some places slightly or more improved. - it tries to provide a platform on which to build much more demos as required as there can be always new ideas about demoing a meaningfull use case on Trinidad, or some component behavior. I have attached the zip file, containing the source code of the showcase Regards, Cosmin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1689) New Trinidad Default Skin - Casablanca
[ https://issues.apache.org/jira/browse/TRINIDAD-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806007#action_12806007 ] Maria Kaval commented on TRINIDAD-1689: --- Would it make sense to document that this is an available skin on the Skinning Dev Guide page? http://myfaces.apache.org/trinidad/devguide/skinning.html New Trinidad Default Skin - Casablanca -- Key: TRINIDAD-1689 URL: https://issues.apache.org/jira/browse/TRINIDAD-1689 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.2.14-core Reporter: Adonis Raul Raduca Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: casablanca.zip, casablancaIntegration.patch, trinidadAdaptation.patch A new more modern skin with a nice-minimalist look. Also a simple and intuitive way to skin Trinidad components using Casablanca selectors stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1697) New Trinidad Components Showcase demo application
[ https://issues.apache.org/jira/browse/TRINIDAD-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806013#action_12806013 ] Catalin Kormos commented on TRINIDAD-1697: -- I can arrange this, will talk to the guy responsible at IRIAN, if they didn't see this message already. New Trinidad Components Showcase demo application - Key: TRINIDAD-1697 URL: https://issues.apache.org/jira/browse/TRINIDAD-1697 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.14-core Reporter: Cosmin Martinconi Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: trinidad-components-showcase.zip A new and improved Trinidad components showcase demo application: - the demo is working only with facelets (there is no jsp version) - we tried to build it so it can be searched online also, currently tried with Google Custom Search, but this didn't work out so smoothly so far. - in general, it replicates the examples available already for Trinidad in the existing demo, in some places slightly or more improved. - it tries to provide a platform on which to build much more demos as required as there can be always new ideas about demoing a meaningfull use case on Trinidad, or some component behavior. I have attached the zip file, containing the source code of the showcase Regards, Cosmin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1677) Tag Documentation to list default value for attributes
[ https://issues.apache.org/jira/browse/TRINIDAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-1677: - Resolution: Fixed Fix Version/s: 1.2.12-plugins Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) Tag Documentation to list default value for attributes -- Key: TRINIDAD-1677 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Assignee: Jeanne Waldman Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch Original Estimate: 24h Remaining Estimate: 24h The tag documentation today does not list the default value for a given attribute of a component. Listing the default value for an attribute will help clarify how a component works for application developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Bernd Bohmann f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1472) Add Support for new Resource API in tomahawk 2.0 module
[ https://issues.apache.org/jira/browse/TOMAHAWK-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806096#action_12806096 ] Werner Punz commented on TOMAHAWK-1472: --- Id say for people who still want to use JSP just make the tomahawk 1.2 branch upwards compatible (which it should be anyway) and then make a clean cut and from then onwards facelets only. Did´t we want to do that anyway, because the community wanted the dojo stuff in but the one Ganesh was doing with dojoFaces which relied entirely on faclets? Add Support for new Resource API in tomahawk 2.0 module --- Key: TOMAHAWK-1472 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1472 Project: MyFaces Tomahawk Issue Type: Task Reporter: Leonardo Uribe -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
+1 Leonardo Uribe schrieb: Hi, I was running the needed tasks to get the 2.0.0-beta release of Apache MyFaces core out. This artifacts are very close to pass all TCK tests. Some corrections has been done from the latest proposed artifacts. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.1-beta [1] 2. Maven artifact group org.apache.myfaces.core v2.0.0-beta [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.0-beta artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces200beta [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces200betabinsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314537 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12314537
[jira] Created: (MYFACES-2517) Problem with flash and GET
Problem with flash and GET
--
Key: MYFACES-2517
URL: https://issues.apache.org/jira/browse/MYFACES-2517
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Michael Kurz
The flash does not work for GET requests. With the two page fragments below the
value of the flash is never displayed on navigating between them.
page1.xhtml:
c:set target=#{flash} property=name value=Michi (from 1)/
h:outputText value=#{flash.name}/
h:link outcome=page2 value=to page2/
page2.xhtml:
c:set target=#{flash} property=name value=Michi (from 2)/
h:outputText value=#{flash.name}/
h:link outcome=page1 value=to page1/
I had a look at FlashImpl and what I did not quite understand was the check for
isPostback() in doPrePhaseActions(). It is ovious that with this check the
old flash will not be passed over if the request is not a postback. When I
remove the check everything works as I would expect it.
What do you guys think, is this a bug or did I miss something?
Thanks to Ingo Hofmann for making me aware of this behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:198) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:677) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig.loadImplicit(TagLibraryConfig.java:708) at
[jira] Resolved: (MYFACES-2514) An empty default-validators in faces-config should disable default validators
[ https://issues.apache.org/jira/browse/MYFACES-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2514. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 An empty default-validators in faces-config should disable default validators --- Key: MYFACES-2514 URL: https://issues.apache.org/jira/browse/MYFACES-2514 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2518) BeanValidator should not be installed if bean validation is not available
BeanValidator should not be installed if bean validation is not available - Key: MYFACES-2518 URL: https://issues.apache.org/jira/browse/MYFACES-2518 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr If you are running MyFaces 2.0 in an environment that does not provide bean validation, the BeanValidator should not be installed as a default validator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2518) BeanValidator should not be installed if bean validation is not available
[ https://issues.apache.org/jira/browse/MYFACES-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2518. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 BeanValidator should not be installed if bean validation is not available - Key: MYFACES-2518 URL: https://issues.apache.org/jira/browse/MYFACES-2518 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 If you are running MyFaces 2.0 in an environment that does not provide bean validation, the BeanValidator should not be installed as a default validator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
[jira] Reopened: (MYFACES-2511) Handle javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR correctly
[ https://issues.apache.org/jira/browse/MYFACES-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr reopened MYFACES-2511: There is still a problem with this parameter: if it is set to true, but there is a default-validators entry in faces-config with javax.faces.Bean, bean validation should be installed. Note that this requires adding the BeanValidator in the code rather than in adding it in standard-faces-config.xml. Handle javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR correctly - Key: MYFACES-2511 URL: https://issues.apache.org/jira/browse/MYFACES-2511 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 If javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR is set to true, the BeanValidator is not installed automatically on all input components. This already works fine. However, the BeanValidator can still be added manually via f:validateBean /, which is not handled correctly at the moment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2517) Problem with flash and GET
[
https://issues.apache.org/jira/browse/MYFACES-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806152#action_12806152
]
Leonardo Uribe commented on MYFACES-2517:
-
It is probably a bug. The examples proposed for flash object (see test-webapp
on current20 for this ones) does not consider an example like the one proposed,
because in that moment all stuff related to GET support was not implemented.
Remove the check should work, but anyway I'll take a look at this one.
Problem with flash and GET
--
Key: MYFACES-2517
URL: https://issues.apache.org/jira/browse/MYFACES-2517
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Michael Kurz
The flash does not work for GET requests. With the two page fragments below
the value of the flash is never displayed on navigating between them.
page1.xhtml:
c:set target=#{flash} property=name value=Michi (from 1)/
h:outputText value=#{flash.name}/
h:link outcome=page2 value=to page2/
page2.xhtml:
c:set target=#{flash} property=name value=Michi (from 2)/
h:outputText value=#{flash.name}/
h:link outcome=page1 value=to page1/
I had a look at FlashImpl and what I did not quite understand was the check
for isPostback() in doPrePhaseActions(). It is ovious that with this check
the old flash will not be passed over if the request is not a postback.
When I remove the check everything works as I would expect it.
What do you guys think, is this a bug or did I miss something?
Thanks to Ingo Hofmann for making me aware of this behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2517) Problem with flash and GET
[
https://issues.apache.org/jira/browse/MYFACES-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2517.
-
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Assignee: Leonardo Uribe
I have checked and all tests we have pass, so we can remove that check
Thanks to Ingo Hofmann and Michael Kurz for provide this fix
Problem with flash and GET
--
Key: MYFACES-2517
URL: https://issues.apache.org/jira/browse/MYFACES-2517
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Michael Kurz
Assignee: Leonardo Uribe
Fix For: 2.0.0-beta-2
The flash does not work for GET requests. With the two page fragments below
the value of the flash is never displayed on navigating between them.
page1.xhtml:
c:set target=#{flash} property=name value=Michi (from 1)/
h:outputText value=#{flash.name}/
h:link outcome=page2 value=to page2/
page2.xhtml:
c:set target=#{flash} property=name value=Michi (from 2)/
h:outputText value=#{flash.name}/
h:link outcome=page1 value=to page1/
I had a look at FlashImpl and what I did not quite understand was the check
for isPostback() in doPrePhaseActions(). It is ovious that with this check
the old flash will not be passed over if the request is not a postback.
When I remove the check everything works as I would expect it.
What do you guys think, is this a bug or did I miss something?
Thanks to Ingo Hofmann for making me aware of this behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
I see, I've double checked and all tag handlers in PrimeFaces use javax.faces.view.facelets.MethodRule, so can't figure out where that class load comes from. Also note that project was working with Mojarra jars. Anyway my vote is 0 now and I would like to hear other testers' results. On Jan 28, 2010, at 11:04 PM, Leonardo Uribe wrote: Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at
[jira] Resolved: (MYFACES-2511) Handle javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR correctly
[ https://issues.apache.org/jira/browse/MYFACES-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2511. Resolution: Fixed Handle javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR correctly - Key: MYFACES-2511 URL: https://issues.apache.org/jira/browse/MYFACES-2511 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 If javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR is set to true, the BeanValidator is not installed automatically on all input components. This already works fine. However, the BeanValidator can still be added manually via f:validateBean /, which is not handled correctly at the moment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2502) Component state is lost for composite component childs of facets relocated by composite:insertChildren or composite:insertFacet
[
https://issues.apache.org/jira/browse/MYFACES-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2502:
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Status: Resolved (was: Patch Available)
Component state is lost for composite component childs of facets relocated by
composite:insertChildren or composite:insertFacet
---
Key: MYFACES-2502
URL: https://issues.apache.org/jira/browse/MYFACES-2502
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2502-2.patch, MYFACES-2502-3.patch,
MYFACES-2502-4.patch
When partial state saving is not used, component state is lost for composite
component childs of facets relocated by composite:insertChildren or
composite:insertFacet
To understand why this is happening, it is necessary to understand how
facelets works in context and how composite:insertChildren and
composite:insertFacet works, so I'll do a resume for it.
In jsf 1.2, a facelet is applied in two cases:
1. When a page is request for first time, the whole component tree is build.
2. On a postback to update transient components like facelets UIInstruction.
To see it in context, suppose a simple app that ask for a name an it print it
on another component on the same page:
h:form
Name: h:inputText value={bean.name}/
Previous Name: h:outputtext value={bean.name}/
h:commandButton value=submit action=submitToThisSamePage/
/h:form
That is what happened when facelets + jsf 1.2 is used:
First Request:
- There is a call to FaceletViewHandler.buildView from
FaceletViewHandler.renderView that cause the UIViewRoot instance to be filled
for first time calling to f.apply().
- The view is rendered.
- Save the state for all non transient components found on the view. This
include save the tree structure too, so it can be reconstructed later.
Postback (The user send his name and do a submit):
- Restore the tree structure and component state for all saved components.
- All lifecycle phases continues until before renderView
- On FaceletViewHandler.renderView there is a call to buildView, and this
one causes all transient components like facelets UIInstruction to be added
to the tree. ComponentHandler first try to detect if the component is on the
view before create it, and if that is true do not create it, instead it takes
this instance and continue apply the taghandles and it remove and add it from
tree, to give the chance to other transient components to be created and
added correctly.
- The view is rendered.
- Save the state for all non transient components found on the view. This
include save the tree structure too, so it can be reconstructed later.
In jsf 2.0 it happens something similar. ViewDeclarationLanguage and
TagHandlerDelegate abstract classes were created, so some code was
relocated. To be clear, the algorithm in jsf 2.0 without partial state
saving is this:
First Request:
- There is a call to ViewDeclarationLanguage.buildView from
RenderResponseExecutor.execute that cause the UIViewRoot instance to be
filled for first time calling to f.apply().
- The view is rendered.
- Save the state for all non transient components found on the view. This
include save the tree structure too, so it can be reconstructed later.
Postback (The user send his name and do a submit):
- Restore the tree structure and component state for all saved components.
- All lifecycle phases continues until before renderView
- On RenderResponseExecutor.execute there is a call to buildView, and this
one causes all transient components like facelets UIInstructions to be added
to the tree. ComponentHandler first try to detect if the component is on the
view before create it, and if that is true do not create it, instead it takes
this instance and continue apply the taghandles and it remove and add it from
tree, to give the chance to other transient components to be created and
added correctly.
- The view is rendered.
- Save the state for all non transient components found on the view. This
include save the tree structure too, so it can be reconstructed later.
The algorithm in jsf 2.0 with partial state saving is different:
First Request:
- There is a call to ViewDeclarationLanguage.buildView from
RenderResponseExecutor.execute that cause the UIViewRoot instance to be
filled for first time calling to f.apply().
- The view is rendered.
- Save the state for all non transient components found on the view that has
delta or was added
[jira] Created: (MYFACES-2519) f:event could be registered twice if it is child of UIViewRoot
f:event could be registered twice if it is child of UIViewRoot -- Key: MYFACES-2519 URL: https://issues.apache.org/jira/browse/MYFACES-2519 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe f:event should not be applied if the parent is instance of UIViewRoot and we are refreshing the component tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2519) f:event could be registered twice if it is child of UIViewRoot
[ https://issues.apache.org/jira/browse/MYFACES-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2519. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 f:event could be registered twice if it is child of UIViewRoot -- Key: MYFACES-2519 URL: https://issues.apache.org/jira/browse/MYFACES-2519 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 f:event should not be applied if the parent is instance of UIViewRoot and we are refreshing the component tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806185#action_12806185 ] Leonardo Uribe commented on MYFACES-2516: - This patch changes the way it is setViewRoot is called. I don't think we can apply that part as is, because the algorithm to setViewRoot is clear (see RestoreViewExecutor and section 2.2 of jsf 2.0 spec) Anyway, I think it is valid apply the remaining part of the patch so I'll commit that one. Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
2010/1/28 Cagatay Civici cagatay.civ...@gmail.com I see, I've double checked and all tag handlers in PrimeFaces use javax.faces.view.facelets.MethodRule, so can't figure out where that class load comes from. Also note that project was working with Mojarra jars. javax.faces.view.facelets.MethodRule does not exist. Are you really sure? I can't find any reference in myfaces source code to anything in com.sun.faces.facelets. Anyway my vote is 0 now and I would like to hear other testers' results. On Jan 28, 2010, at 11:04 PM, Leonardo Uribe wrote: Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at
Re: [VOTE] release for myfaces core 2.0.0-beta
Hi Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag.MethodRule regards, Leonardo Uribe 2010/1/28 Leonardo Uribe lu4...@gmail.com 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com I see, I've double checked and all tag handlers in PrimeFaces use javax.faces.view.facelets.MethodRule, so can't figure out where that class load comes from. Also note that project was working with Mojarra jars. javax.faces.view.facelets.MethodRule does not exist. Are you really sure? I can't find any reference in myfaces source code to anything in com.sun.faces.facelets. Anyway my vote is 0 now and I would like to hear other testers' results. On Jan 28, 2010, at 11:04 PM, Leonardo Uribe wrote: Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806212#action_12806212 ] Leonardo Uribe commented on MYFACES-2516: - Note the committed code uses ComponentSupport.getViewRoot instead facesContext.getViewRoot(). If f:event is inside f:metadata we don't have a NullpointerException, but if we have f:event inside a component inside f:metadata we have it. Does this apply for your use case? Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806206#action_12806206 ] Bernd Bohmann edited comment on MYFACES-2516 at 1/29/10 4:13 AM: - That is the reason why i don't apply the patch. If f:event is a direct child of f:metadata you don't get the UIViewRoot from the parent or from the FacesContext. How we can get the ViewRoot in this case? was (Author: bommel): That is the reason why i don't apply the patch. If f:event is not a direct child of UIViewRoot you don't get the UIViewRoot from the parent or the FacesContext. Should we file an issue agains the spec? Without setting the ViewRoot you get a NullpointerException. Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806223#action_12806223 ] Bernd Bohmann commented on MYFACES-2516: I see it. If f:event is inside f:metadata i get a NullpointerException. The metadata facet of UIViewRoot is set after nextHandler.apply because of ComponentHandler.isNew() should return true. Where is the metadata contract defined? Which kind of tags are allowed in the metadata tag? Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2483) Find a way to allow c:if work with partial state saving enabled
[ https://issues.apache.org/jira/browse/MYFACES-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806226#action_12806226 ] Leonardo Uribe commented on MYFACES-2483: - Provided another prototype. It works but still is pending how to deal with c:if inside UIViewRoot directly and how to remove PostBuildComponentTreeOnRestoreViewEvent, to enhance compatibility. The strategy applied is: 1. Mark the parent component containing c:if or any tag that causes component addition based on the application model to not save it partially. 2. Handle the changes for composite:insertChildren/composite:insertFacet using the algorithm on MYFACES-2502 3. At the end of apply the facelet in vdl.buildView, do not force publish PreRemoveFromViewEvent - PostAddToViewEvent, instead use PostBuildComponentTreeOnRestoreViewEvent (Maybe we have to change this name to something more descriptive). This is necessary because otherwise the listener DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener register all components to be saved and restored. The idea is create a param called org.apache.myfaces.PARAM_REFRESH_TRANSIENT_BUILD_ON_PSS. This param only works when partial state saving is enabled. If we do the example proposed in MYFACES-2502, the algorithm when this param is true will be: First Request: - There is a call to ViewDeclarationLanguage.buildView from RenderResponseExecutor.execute that cause the UIViewRoot instance to be filled for first time calling to f.apply(). - The view is rendered. - Save the state for all non transient components found on the view that has delta or was added after build. This does not include the structure, because all state is just saved on a big MapString,Object where the keys are the clientId for each component. Postback (The user send his name and do a submit): - StateManagementStrategy.restoreView calls ViewDeclarationLanguage.buildView passing an empty UIViewRoot to be filled for first time calling to f.apply(). - Restore the component state for all saved components. Note the tree structure now is already provided. - All lifecycle phases continues until before renderView - On RenderResponseExecutor.execute there is a call to buildView, and this one causes all transient components like facelets UIInstructions to be added to the tree. ComponentHandler first try to detect if the component is on the view before create it, and if that is true do not create it, instead it takes this instance and continue apply the taghandles and it remove and add it from tree, to give the chance to other transient components to be created and added correctly. - The view is rendered. - Save the state for all non transient components found on the view that has delta or was added after build. This does not include the structure, because all state is just saved on a big MapString,Object where the keys are the clientId for each component. Find a way to allow c:if work with partial state saving enabled --- Key: MYFACES-2483 URL: https://issues.apache.org/jira/browse/MYFACES-2483 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: fixPSSIf2009JAN-10.patch, fixPSSIf2009JAN-7.patch This one is difficult to solve but I still think it is possible. It was explored trying to solve MYFACES-2428, and it seems ri is trying to do something about it too on: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408 and https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313 One strategy to solve this one is this: 1. Mark the parent component containing c:if to not save it partially. 2. Do not execute c:if on postback and partial state saving enabled. In theory, the parent component should be restored fully from saved state. Note that things like: c:if pSome markup/p c:if is just invalid. It is expected that c:if only contains components with state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806231#action_12806231 ] Leonardo Uribe commented on MYFACES-2516: - In theory it is expected f:metadata could contains f:viewParam and f:event tags. UIViewParameter extends from UIInput, so it also f:viewParam could contains converter and validator tags. f:metadata is a facet with multiple components, so in theory inside UIViewRoot.METADATA_FACET_NAME there should be only one UIPanel (optional) and one or many UIViewParameter instances. With the latest code (using ComponentSupport.getViewRoot), use f:event inside f:metadata should work without problem. Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806236#action_12806236 ] Bernd Bohmann commented on MYFACES-2516: Have you try it? I get a java.lang.NullPointerException at org.apache.myfaces.view.facelets.tag.jsf.core.EventHandler.apply(EventHandler.java:114) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at org.apache.myfaces.view.facelets.tag.jsf.core.ViewMetadataHandler.apply(ViewMetadataHandler.java:69) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:103) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage$FaceletViewMetadata.createMetadataView(FaceletViewDeclarationLanguage.java:1854) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:148) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) Once again You can not get the UIViewRoot from the parent in ComponentSupport. The metadata facet of UIViewRoot is set after nextHandler.apply in ViewMetadataHandler because ComponentHandler.isNew() should return true in EventHandler. Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[
https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806241#action_12806241
]
Leonardo Uribe commented on MYFACES-2516:
-
Ouch, that's true. To solve this one we have to change the current
ViewMetadataHandler implementation.
The implementation of FacetHandler looks like this:
public void apply(FaceletContext ctx, UIComponent parent) throws
IOException, FacesException, FaceletException,
ELException
{
if (parent == null)
{
throw new TagException(this.tag, Parent UIComponent was null);
}
parent.getAttributes().put(KEY, this.name.getValue(ctx));
try
{
this.nextHandler.apply(ctx, parent);
}
finally
{
parent.getAttributes().remove(KEY);
}
}
There is no creation of panel here (it is done indirectly from
ComponentTagHandlerDelegate). Maybe we can set and remove FacetHandler.KEY like
in FacetHandler, also create a panel like it is present, then change the call
of call
this.nextHandler.apply(ctx, parent);
instead
this.nextHandler.apply(ctx, metadataFacet);
And in theory that should work.
Allow any child for f:event in the case of a PreRenderViewEvent
---
Key: MYFACES-2516
URL: https://issues.apache.org/jira/browse/MYFACES-2516
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Bernd Bohmann
Assignee: Leonardo Uribe
Attachments: MYFACES-2516.patch
f:event currently only supports the UIViewRoot as a child for the
PreRenderViewEvent
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[
https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806244#action_12806244
]
Leonardo Uribe commented on MYFACES-2516:
-
The final code looks like this:
UIComponent metadataFacet =
parent.getFacet(UIViewRoot.METADATA_FACET_NAME);
if (metadataFacet == null)
{
metadataFacet = ctx.getFacesContext().
getApplication().createComponent(UIPanel.COMPONENT_TYPE);
metadataFacet.setId(UIViewRoot.METADATA_FACET_NAME);
parent.getFacets().put(UIViewRoot.METADATA_FACET_NAME,
metadataFacet);
}
parent.getAttributes().put(FacetHandler.KEY,
UIViewRoot.METADATA_FACET_NAME);
try
{
this.nextHandler.apply(ctx, parent);
}
finally
{
parent.getAttributes().remove(FacetHandler.KEY);
}
Does that work?
Allow any child for f:event in the case of a PreRenderViewEvent
---
Key: MYFACES-2516
URL: https://issues.apache.org/jira/browse/MYFACES-2516
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Bernd Bohmann
Assignee: Leonardo Uribe
Attachments: MYFACES-2516.patch
f:event currently only supports the UIViewRoot as a child for the
PreRenderViewEvent
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
What said the Debugger regarding the 'why'? Sent from my iPod. On 29.01.2010, at 01:38, Cagatay Civici cagatay.civ...@gmail.com wrote: I see, I've double checked and all tag handlers in PrimeFaces use javax.faces.view.facelets.MethodRule, so can't figure out where that class load comes from. Also note that project was working with Mojarra jars. Anyway my vote is 0 now and I would like to hear other testers' results. On Jan 28, 2010, at 11:04 PM, Leonardo Uribe wrote: Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/ faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap (ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle (ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase (LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute (LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter (CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter (FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run (JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/ tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary $UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent (AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig $TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig $LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement( AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement( XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$ FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next (XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next( XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument( XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
ProjectStage logger msgs (was: Fwd: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration)
I like Dan's proposal. *** WARNING: Apache MyFaces is running in DEVELOPMENT mode. *** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** -Matthias -- Forwarded message -- From: Dan Allen dan.j.al...@gmail.com Date: Wed, Jan 27, 2010 at 7:33 PM Subject: Re: [jsr-314-open] [jsf2next] PROJECT_STAGE system property configuration To: jsr-314-open jsr-314-o...@jcp.org For the implementations, it might be a good idea to borrow the log message the Wicket uses when running in development mode. *** WARNING: JavaServer Faces is running in DEVELOPMENT mode.*** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** (Of course, if we eventually settle on a platform-wide flag, then the message can be updated appropriately). Just something I noticed while working on a Wicket-related issue in Weld. -Dan On Wed, Jan 27, 2010 at 12:38 AM, Lincoln Baxter, III lincolnbax...@gmail.com wrote: We need to make sure we are clear whether the context parameter overrides the system property, or vice versa. I would think the system property would take precedence, but I'm open to counter arguments. Definitely need to flush out the solution of least surprise. I think that people will expect the system property to override web.xml - This would allow production servers to set the property and ensure that no matter what is deployed (accidents occur), they are *always* running in Production stage mode. At first thought, allowing web.xml to override the system property seems to allow greater flexibility, but in fact, it provides equal flexibility because you could simply leave your development stages at Development or whatever.. in web.xml, then disable the system-property when needed, allowing the same flexibility (as an inverse operation.) I am in favor of the System property overriding web.xml. I don't think it makes sense otherwise. --LB On Tue, Jan 26, 2010 at 6:32 PM, Dan Allen dan.j.al...@gmail.com wrote: On Tue, Jan 19, 2010 at 5:03 PM, Andy Schwartz andy.schwa...@oracle.com wrote: Ed Burns wrote: On Mon, 18 Jan 2010 15:16:20 -0500, Andy Schwartz andy.schwa...@oracle.com said: AS https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=499 AS Can we add this to the MR list? Yes, but I'd like to get agreement that we don't care about the Servlet EG's opinion on the VM-wide nature of system properties. Okay, thanks for the update Ed. I wasn't aware that there had been push back from the Servlet EG on this. Personally I don't understand the nature of the objection. In some case fine-grained (application-specific) control is desired. We have addressed this case via the context parameter. There seems to be general agreement in our EG that a system-level property would also be beneficial and in particular would improve the ease of use of this feature for development-time scenarios (ie. no need for a web.xml or JNDI config). Not sure why we need to choose one approach vs. the other. Both serve a purpose. The system property seems like a very reasonable option to me. It matches well with starting the server in debug mode and I could even see the two being tied together in an IDE server control (tangential to this decision, of course). Just like with debug mode, this should be something that can be controlled without a change to application code. We need to make sure we are clear whether the context parameter overrides the system property, or vice versa. I would think the system property would take precedence, but I'm open to counter arguments. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com Keep it Simple -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[
https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806253#action_12806253
]
Bernd Bohmann commented on MYFACES-2516:
My code looks like this:
UIComponent metadataFacet = parent.getFacet(UIViewRoot.METADATA_FACET_NAME);
if (metadataFacet == null)
{
metadataFacet =
ctx.getFacesContext().getApplication().createComponent(UIPanel.COMPONENT_TYPE);
metadataFacet.setId(UIViewRoot.METADATA_FACET_NAME);
metadataFacet.getAttributes().put(ComponentSupport.FACET_CREATED_UIPANEL_MARKER,
true);
parent.getFacets().put(UIViewRoot.METADATA_FACET_NAME,
metadataFacet);
}
parent.getAttributes().put(FacetHandler.KEY,
UIViewRoot.METADATA_FACET_NAME);
try
{
this.nextHandler.apply(ctx, parent);
}
finally
{
parent.getAttributes().remove(FacetHandler.KEY);
}
Allow any child for f:event in the case of a PreRenderViewEvent
---
Key: MYFACES-2516
URL: https://issues.apache.org/jira/browse/MYFACES-2516
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Bernd Bohmann
Assignee: Leonardo Uribe
Attachments: MYFACES-2516.patch
f:event currently only supports the UIViewRoot as a child for the
PreRenderViewEvent
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806255#action_12806255 ] Bernd Bohmann commented on MYFACES-2516: Should I commit? Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Leonardo Uribe Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806258#action_12806258 ] Matthias Weßendorf commented on MYFACES-2516: - +1 yes, please commit it Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
