Re: [VOTE] Release of MyFaces Core 2.2.6
+1 Cheers, Jakob 2014-11-13 12:22 GMT+01:00 Werner Punz werner.p...@gmail.com: +1 Am 13.11.14 04:12, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.2.6 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.6 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.2.6 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] https://repository.apache.org/content/repositories/orgapachemyfaces-1035/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces226binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12328703 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions Validator 2.0.8
+1 Cheers, Jakob 2014-05-27 22:34 GMT+02:00 Hazem Saleh hazem.sa...@gmail.com: +1 Sent from my iPhone On May 27, 2014, at 8:19 PM, Werner Punz werner.p...@gmail.com wrote: +1 Werner Am 27.05.14 10:14, schrieb Gerhard Petracek: +1 regards, gerhard 2014-05-27 8:29 GMT+02:00 Gerhard Petracek gpetra...@apache.org mailto:gpetra...@apache.org: Hi, we were running the needed tasks to get the 8th release of Apache MyFaces Extensions Validator out. The artifacts are deployed to Nexus [1]. The release contains the following modules for JSF 2.x: - ExtVal Core - ExtVal Property-Validation - ExtVal Bean-Validation - Trinidad-Support-Module - Generic-Support-Module Please take a look at the 2.0.8 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1024/org/apache/myfaces/extensions/validator/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of MyFaces Test 1.0.7
+1 Cheers, Jakob 2014-05-26 14:43 GMT+02:00 Leonardo Uribe lu4...@gmail.com: +1 2014-05-26 14:43 GMT+02:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.7 release of Apache MyFaces Test out. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.7 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.7 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] https://repository.apache.org/content/repositories/orgapachemyfaces-1023/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest107binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12327053 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of MyFaces Test 1.0.6
+1 Regards, Jakob 2014-02-13 1:12 GMT+01:00 Leonardo Uribe lu4...@gmail.com: +1 2014-02-12 19:11 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.6 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of Myfaces Core 2.2.1. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.6 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.6 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] https://repository.apache.org/content/repositories/orgapachemyfaces-1000/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest106binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12326250 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] svn-keywords and @author tags
+1 Regards, Jakob 2013/10/14 Gerhard Petracek gpetra...@apache.org: hi @ all, we already had a discussion as well as an agreement about it (starting point: [1]). in several modules the cleanup is finished. however, since we still have (even new) parts which contain svn-keywords and/or @author tags, i start this formal vote. please vote with - [ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining) [ ] +0 [ ] -1 for: we should keep svn-keywords and @author tags - regards, gerhard [1] http://s.apache.org/ZtS -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3638) NPE in ServerSideStateCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496988#comment-13496988
]
Jakob Korherr commented on MYFACES-3638:
404 should force an immediate responseComplete() IMHO.
NPE in ServerSideStateCacheImpl
---
Key: MYFACES-3638
URL: https://issues.apache.org/jira/browse/MYFACES-3638
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg
Attachments: MYFACES-3638.patch
I'm getting the following NPE when having a request which leads to a 404:
{code}
Nov 9 09:00:45 j02 java.lang.NullPointerException
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1413)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl$CounterSessionViewStorageFactory.createSerializedViewKey(ServerSideStateCacheImpl.java:1392)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:318)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:1036)
Nov 9 09:00:45 j02 at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:149)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:253)
Nov 9 09:00:45 j02 at
org.apache.myfaces.shared.view.JspViewDeclarationLanguageBase.renderView(JspViewDeclarationLanguageBase.java:221)
Nov 9 09:00:45 j02 at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.tomahawk.application.ResourceViewHandlerWrapper.renderView(ResourceViewHandlerWrapper.java:93)
Nov 9 09:00:45 j02 at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
Nov 9 09:00:45 j02 at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
Nov 9 09:00:45 j02 at
org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:126)
Nov 9 09:00:45 j02 at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Hi, Big +1, that's a very great idea! Also it should not be too hard to implement, since the most stuff does already exist in codi/deltaspike, right? Regards, Jakob 2012/7/18 Gerhard Petracek gerhard.petra...@gmail.com: hi david, it would be a myfaces specific api which can be used by myfaces-core itself and myfaces specific adapters (e.g. provided by myfaces codi and apache deltaspike). the api in javax.faces.* won't be changed before v2.2.x (we aren't allowed to do it earlier). i also think tomee users would benefit from it. they won't use it directly, but they would benefit from the mentioned fixes (+ adapters). regards, gerhard 2012/7/18 David Blevins david.blev...@gmail.com Could be pretty good think to get in front of TomEE user's faces. JSF is certainly one of the major draws and I bet people would be excited about it. Do you know if this adds any changes to the javax.faces.* package? -David On Wed, Jul 18, 2012 at 12:00 PM, Mark Struberg strub...@yahoo.de wrote: yikes, big +1 Would be a cool playground for getting this finally done - this issue is open in the spec tracker since 2004 now ;) LieGrue, strub From: Gerhard Petracek gpetra...@apache.org To: MyFaces Development dev@myfaces.apache.org Sent: Wednesday, July 18, 2012 7:13 PM Subject: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x hi @ all, you might know that jsf 2.2 will introduce ClientWindow (= window-id). besides the basic multi-tab handling (separation), it also allows to fix state-saving (- also view-scope) as well as the flash-scope for multi-tab/window constellations. since it's an important topic, we should discuss if it makes sense to port it to myfaces-core 2.0.x and 2.1.x. e.g. we could try to implement it for myfaces-core 2.0.x and 2.1.x with a myfaces specific api - the official api provided by myfaces core 2.2.x could just delegates to it. besides fixing the mentioned issues, we can also provide myfaces specific adapters for myfaces codi and apache deltaspike. users of myfaces-core v2.0.x and v2.1.x would benefit from this optional feature (deactivated by default) and it allows us to get feedback about the implementation (and possible issues) even before users start using myfaces-core 2.2.x. the disadvantage is that it’s some extra work to do. regards, gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.5
+1 Regards, Jakob 2012/4/5 hazem.sa...@gmail.com: +1 Sent from my iPhone On Apr 5, 2012, at 9:13 PM, Martin Koci martin.kocicak.k...@gmail.com wrote: +1 Gerhard Petracek píše v Čt 05. 04. 2012 v 10:36 +0200: Hi, I was running the needed tasks to get the 12th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.5 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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.5/myfaces-extcdi-parent-1.0.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] refactor shared as proposed earlier on branch
+1 Regards, Jakob 2012/3/8 Werner Punz werner.p...@gmail.com: +1 Werner Am 08.03.12 11:51, schrieb Mark Struberg: +1 LieGrue, strub From: Gerhard Petracekgerhard.petra...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org Sent: Thursday, March 8, 2012 11:36 AM Subject: Re: [core] refactor shared as proposed earlier on branch +1 regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/3/8 Leonardo Uribelu4...@gmail.com Hi I think it is a good time to refactor shared as it was proposed in: http://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x_refactor_shade_duplicate/ See the discussion on: http://markmail.org/message/ujqdvipurs6zzju5?q=[DISCUSS]+how+to+get+rid+of+tons+of+duplicated+code Note it is a good time to create 2.2.x branch too, but before that we should reorganize myfaces core project layout to minimize the overhead associated with maintain multiple branches. If no objections I'll do the proposed changes soon (this weekend). Suggestions are welcome. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.4
+1 Regards, Jakob 2012/2/14 Mark Struberg strub...@yahoo.de: +1 LieGrue, strub - Original Message - From: Martin Koci martin.kocicak.k...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Monday, February 13, 2012 7:23 PM Subject: Re: [VOTE] Release of Extensions CDI (CODI) 1.0.4 +1 Gerhard Petracek píše v Po 13. 02. 2012 v 17:59 +0100: Hi, I was running the needed tasks to get the 11th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.4 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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-224/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-224/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.4/myfaces-extcdi-parent-1.0.4-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: creating a git read-only clone of tomahawk?
At least it can't hurt to have one, +1 from me! Regards, Jakob 2012/1/13 Mark Struberg strub...@yahoo.de: Hi! I've recently heard of interest of having a git mirror of our tomahawk project. WDYT? LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.3
+1 Regards, Jakob 2012/1/9 Werner Punz werner.p...@gmail.com: +1 Am 08.01.12 21:22, schrieb Gerhard Petracek: +1 regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/1/8 Gerhard Petracek gpetra...@apache.org mailto:gpetra...@apache.org Hi, I was running the needed tasks to get the 10th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.3 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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-034/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.3/myfaces-extcdi-parent-1.0.3-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [codi] first steps for the next release
+1 Regards, Jakob 2012/1/2 Gerhard Petracek gerhard.petra...@gmail.com: hi @ all, if there are no objections, i'll start with the first steps for the next release (review,...) by the end of the week. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions Validator 1.2.5 and 2.0.5
+1 Regards, Jakob 2011/12/18 Matt Benson gudnabr...@gmail.com: +1 Matt On Sun, Dec 18, 2011 at 12:58 PM, Hazem Saleh haz...@apache.org wrote: ++1 On Sun, Dec 18, 2011 at 1:09 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard 2011/12/18 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 5th release of Apache MyFaces Extensions Validator out. The artifacts are deployed to Nexus [1-2]. These 2 releases contain the following modules for JSF 1.2, JSF 2.0: - ExtVal Core - ExtVal Property-Validation - ExtVal Bean-Validation (Integration + additional features for using JSR 303 with JSF 1.2 and 2.x) - Trinidad-Support-Module - Generic-Support-Module Please take a look at the 1.2.5 and 2.0.5 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, Gerhard [1] http://repository.apache.org/content/repositories/orgapachemyfaces-363/org/apache/myfaces/extensions/validator/ [2] http://repository.apache.org/content/repositories/orgapachemyfaces-364/org/apache/myfaces/extensions/validator/ [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.2
+1 Regards, Jakob 2011/12/3 Mark Struberg strub...@yahoo.de: +1 LieGrue, strub From: Gerhard Petracek gpetra...@apache.org To: MyFaces Development dev@myfaces.apache.org Sent: Saturday, December 3, 2011 2:49 AM Subject: [VOTE] Release of Extensions CDI (CODI) 1.0.2 Hi, I was running the needed tasks to get the 9th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.2 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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-289 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-289/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.2/myfaces-extcdi-parent-1.0.2-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.11 (take 2)
+1 Regards, Jakob 2011/12/1 Leonardo Uribe lu4...@gmail.com: +1 2011/11/30 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.11 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.11 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.11 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.11 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] https://repository.apache.org/content/repositories/orgapachemyfaces-276/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces2011binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319078 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.5 (take 2)
+1 Regards, Jakob 2011/12/1 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.5 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] https://repository.apache.org/content/repositories/orgapachemyfaces-277/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces215binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319076 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [codi] first steps for the next release
+1 :) Regards, Jakob 2011/11/29 Mark Struberg strub...@yahoo.de: yes big +1 :) LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tuesday, November 29, 2011 7:37 AM Subject: [codi] first steps for the next release hi @ all, if there are no objections, i'll start with the first steps for the next release (review,...). it would be great to start with the release procedure by the end of the week. regards, gerhard http://www.irian.at Your JSF/JEE powerhouse - JEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.11
Hi, What happened to this vote? Regards, Jakob 2011/11/23 Volker Weber v.we...@inexso.de: Hi, +1 Regards, Volker 2011/11/23 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.11 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.11 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.11 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.11 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] https://repository.apache.org/content/repositories/orgapachemyfaces-234/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces2011binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319078 -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.11
Then please close the vote(s) as invalid! Regards, Jakob 2011/11/30 Leonardo Uribe lu4...@gmail.com: Hi We need to fix the MYFACES-3412 and revote the artifacts. regards, Leonardo Uribe 2011/11/29 Jakob Korherr jakob.korh...@gmail.com: Hi, What happened to this vote? Regards, Jakob 2011/11/23 Volker Weber v.we...@inexso.de: Hi, +1 Regards, Volker 2011/11/23 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.11 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.11 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.11 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.11 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] https://repository.apache.org/content/repositories/orgapachemyfaces-234/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces2011binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319078 -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.5
+1 Regards, Jakob Am Mittwoch, 23. November 2011 schrieb Leonardo Uribe lu4...@gmail.com: +1 2011/11/23 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.5 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] https://repository.apache.org/content/repositories/orgapachemyfaces-233/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces215binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319076 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.11
+1 Regards, Jakob Am Mittwoch, 23. November 2011 schrieb Leonardo Uribe lu4...@gmail.com: +1 2011/11/23 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.11 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.11 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.11 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.11 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] https://repository.apache.org/content/repositories/orgapachemyfaces-234/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces2011binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319078 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
JSF value expression injection vulnerability
Hi all, As it turns out we have a pretty big security hole in JSF 2.x (myfaces and mojarra). Please check out my blog entry for further infos: http://www.jakobk.com/2011/11/jsf-value-expression-injection-vulnerability/ @leo: can you take care of the bug? Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3405) includeViewParameters re-evaluates param/model values as EL expressions
[ https://issues.apache.org/jira/browse/MYFACES-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155485#comment-13155485 ] Jakob Korherr commented on MYFACES-3405: The patch looks good, +1 on committing. Have you tried it with http://code.google.com/a/apache-extras.org/p/jsf-includeviewparams-security-hole-example/ ? Regards, Jakob includeViewParameters re-evaluates param/model values as EL expressions --- Key: MYFACES-3405 URL: https://issues.apache.org/jira/browse/MYFACES-3405 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3 Environment: MyFaces 2.1.3 Reporter: Frederick Kämpfer Attachments: MYFACES-3405-1.patch I just wanted to make you aware of the following security issue in conjunction with the includeViewParameters navigation parameter. It seems it is also reproducible with MyFaces: http://java.net/jira/browse/JAVASERVERFACES-2247 I'm not sure which workaround would be best in accordance with the Spec, but at least a quick fix might be worth considering to improve the security of the default behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core extcdi] is required to create another proposal about windowId?
scopes, it sounds reasonable to provide an alternate Flash scope in CODI. If we can just modify the logic inside server side state to include windowId concept, it will be enough. MS To come over this, we need to store the n last views not only per session, MS but also per browser tab (==windowId). MS Of course, there can be lots of fancy stuff done to detect closed tabs, MS etc. But all this is much more stable if we really have the opportunity MS to distinguish between tabs. We can e.g. also introduce a configuration MS for maximum allowed tabs, to reduce memory blasting. Really since all state is stored in session, if the session is invalidated all tabs are removed from memory. Basically we already have params for max number of sessions and max number of logical sessions (which in fact can be seen as tabs). So what we have right now is ok, we just need to include windowId concept into the logic and that's it. MS All this is actually completely independent of how the windowId get's MS created and checked imo. Yes, that's right. MS I now tend to do the following (just atm creating a better playground MS example in CODI + hack on the ClientSideWindowHandler): MS MS a.) the cookie thingy is pretty bääh. it just doesn't work if a user clicks MS quickly through a list and opens lots of 'detail pages' on different tabs MS within 2 seconds. MS MS b.) it's currently a 'one or the other' thingy, and I now thought about MS combining the lazyWindowIdDropp.js and the current windowhandler.js MS MS My current research goes into the direction of MS MS 1.) always adding the windowId to each and every link and transport the MS windowId only via this parameter. MS MS 2.) For HTML5-browsers (detected via UserAgent) I render the MS windowhandler.html intermediate page which does all the fancy stuff of MS dynamically applying the old DOM on the intermediate page, etc. For other MS clients we rely on the lazyWindowId script. Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces core server side state saving (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative proposed in this mail (WindowIdRenderKitAware interface, and then use a RenderKit wrapper). regards, Leonardo Uribe 2011/11/18 Mark Struberg strub...@yahoo.de: I now tend to do the following (just atm creating a better playground example in CODI + hack on the ClientSideWindowHandler): a.) the cookie thingy is pretty bääh. it just doesn't work if a user clicks quickly through a list and opens lots of 'detail pages' on different tabs within 2 seconds. b.) it's currently a 'one or the other' thingy, and I now thought about combining the lazyWindowIdDropp.js and the current windowhandler.js My current research goes into the direction of 1.) always adding the windowId to each and every link and transport the windowId only via this parameter. 2.) For HTML5-browsers (detected via UserAgent) I render the windowhandler.html intermediate page which does all the fancy stuff of dynamically applying the old DOM on the intermediate page, etc. For other clients we rely on the lazyWindowId script. Any help is welcome. LieGrue, strub - Original Message - From: Jakob Korherr jakob.korh...@gmail.com To: MyFaces Development dev@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Friday, November 18, 2011 2:23 PM Subject: Re: [core extcdi] is required to create another proposal about windowId? Hi, PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction: https://github.com/balupton/history.js/wiki/Intelligent-State-Handling This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach. Yeap, I did some research in this area and also came across https://github.com/balupton/history.js (there are actually a hand full of projects on github which accomplish the same thing). This sure is a very good way of implementing a rich web 2.0 application with working history (-- back button), facebook and twitter are surely the most famous examples of this technique. However, Mark is right: doing this, you will end up in a lot of browser related problems when it comes to dynamic loading of stylesheets, scripts, etc.. Facebook and twitter managed to get this working for their purposes, but IMO it is not that easy for a standard JSF developer/architect. Regards, Jakob 2011/11/18 Mark Struberg strub...@yahoo.de: Hi! The ClientSideWindowHandler solution
Re: [VOTE] release of myfaces core 1.2.11
+1 Regards, Jakob 2011/11/18 Mark Struberg strub...@yahoo.de: +1 source-release.zip looks good. Happy that I dont use JSF-1.x anymore, so I cannot say anything about the runtime quality ;) LieGrue, strub From: Grant Smith work.gr...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Friday, November 18, 2011 7:29 PM Subject: Re: [VOTE] release of myfaces core 1.2.11 +1 On Thu, Nov 17, 2011 at 11:47 AM, Leonardo Uribe lu4...@gmail.com wrote: +1 2011/11/17 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.2.11 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v3.0.10 [1] 2. Maven artifact group org.apache.myfaces.core v1.2.11 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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 1.2.11 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] https://repository.apache.org/content/repositories/orgapachemyfaces-205/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/%7Elu4242/myfaces1211binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316650 -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.10
+1 Regards, Jakob 2011/11/18 Mark Struberg strub...@yahoo.de: looks good +1 LieGrue, strub - Original Message - From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Thursday, November 17, 2011 6:53 AM Subject: [VOTE] release of myfaces core 2.0.10 Hi, I was running the needed tasks to get the 2.0.10 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.10 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.10 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.10 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] https://repository.apache.org/content/repositories/orgapachemyfaces-201/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces2010binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317870 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.4 (take 2)
+1 Regards, Jakob 2011/11/18 Mark Struberg strub...@yahoo.de: +1 successfully tested with our app. source release looks fine too. LieGrue, strub - Original Message - From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Thursday, November 17, 2011 1:12 AM Subject: [VOTE] release of myfaces core 2.1.4 (take 2) Hi, I was running the needed tasks to get the 2.1.4 release of Apache MyFaces core out. This release has a lot of improvements, including jsf.js modular includes ( http://goo.gl/aYYIH ) and others. The artifacts passed all TCK tests, and include the fix over js part, thanks to Werner. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.4 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] https://repository.apache.org/content/repositories/orgapachemyfaces-200/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces214binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317868 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core extcdi] is required to create another proposal about windowId?
Hi, PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction: https://github.com/balupton/history.js/wiki/Intelligent-State-Handling This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach. Yeap, I did some research in this area and also came across https://github.com/balupton/history.js (there are actually a hand full of projects on github which accomplish the same thing). This sure is a very good way of implementing a rich web 2.0 application with working history (-- back button), facebook and twitter are surely the most famous examples of this technique. However, Mark is right: doing this, you will end up in a lot of browser related problems when it comes to dynamic loading of stylesheets, scripts, etc.. Facebook and twitter managed to get this working for their purposes, but IMO it is not that easy for a standard JSF developer/architect. Regards, Jakob 2011/11/18 Mark Struberg strub...@yahoo.de: Hi! The ClientSideWindowHandler solution in CODI looks good so far, but there is still a lot to do. And like every technology, it has it's pros and cons... What do you think about making the windowId provider pluggable in MyFaces core first? The REAL problem with JSF and multiple tabs is that once you open 2 tabs and click in 1 of them often enough, then you will destroy the state of the view in the other tab as well somewhen. Usually after 20 requests (default). To come over this, we need to store the n last views not only per session, but also per browser tab (==windowId). Of course, there can be lots of fancy stuff done to detect closed tabs, etc. But all this is much more stable if we really have the opportunity to distinguish between tabs. We can e.g. also introduce a configuration for maximum allowed tabs, to reduce memory blasting. All this is actually completely independent of how the windowId get's created and checked imo. LieGrue, strub PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction: https://github.com/balupton/history.js/wiki/Intelligent-State-Handling This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach. - Original Message - From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Thursday, November 17, 2011 9:39 PM Subject: Re: [core extcdi] is required to create another proposal about windowId? Hi Gerhard Ok, good to know that. I'll work on a solution based on the previous discussions about it to have more options in this case. regards, Leonardo Uribe 2011/11/17 Gerhard Petracek gerhard.petra...@gmail.com: hi leo, as soon as the new approach works, we can suggest it for jsf 2.2. however, since it's only compatible with html5, we have to suggest a 2nd approach (e.g. the default behaviour of codi). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/17 Werner Punz werner.p...@gmail.com: Am 11/17/11 7:15 PM, schrieb Leonardo Uribe: Hi In the last days there was some work in these issues: (EXTCDI-242) improve ClientSideWindowHandler windowId passing via cookie (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify if it should get applied per Request (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering, etc Just one question: if the flickering problem was fixed on the current solution done on EXTCDI, it is still necessary to create an implementation inside myfaces core for windowId? This problem is on my list of things to do, so it is better to ask first. regards, Leonardo Uribe Good question, I guess we need something for WindowID handling for jsf2.2 especially given in hindisght of what is planned for 2.2 according to Ed Burns blog but the final answer for now is up to the CODI guys. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Result (Was: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches)
+1 Regards, Jakob 2011/11/8 Bernd Bohmann bernd.bohm...@atanion.com: +1 On Tue, Nov 8, 2011 at 8:01 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Following the previous discussion about MYFACES-2552 (see this thread): http://markmail.org/message/kreytqexrucair2k?q=%5BVOTE%5D+fix+MYFACES-2552+for+2%2E0%2Ex+and+2%2E1%2Ex+branches I have attached a new patch ( MYFACES-2552-4.patch ) adding a param called org.apache.myfaces.STRICT_JSF_2_CC_EL_RESOLVER (following Bernd suggestion) with this documentation: /** * Change default getType() behavior for composite component EL resolver, from return null (see JSF 2_0 spec section 5_6_2_2) to * use the metadata information added by composite:attribute, ensuring components working with chained EL expressions to find the * right type when a getType() is called over the source EL expression. * * To ensure strict compatibility with the spec set this param to true (by default is false, so the change is enabled by default). */ This is the last pending issue for the next release of myfaces core 2.1.4 / 2.0.10. If no objections I'll commit this patch soon. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Re: java.lang.IllegalStateException: zip file closed
Hmm, I don't know. Looking at the code in MyFaces I found out that MyFaces uses Resource.getURL() to get the file from the jar archive. Then it uses URL.openConnection() (or openStream()) to access the resource. Maybe jetty has a concurrency issue here, I don't know, but it really looks that way. Maybe you can have a look at the code in jetty and get some clearance about what happens! Regards, Jakob 2011/10/27 gregor.jari...@raibau.at: Hi Jakob, thank you for your answer. I agree to your explanation. Although I believe Jetty does work as expected. It allows concurrent exceptions, the only thing it is missing is the fact that it returns input streams also when they are closed. I would assume that it would be more suitable if jetty would check if the connection is still open, otherwise open a new one and return that. Nevertheless, as stated previously I have tried out the Jetty patch. What wonders me the most is that the stream still gets closed (probably by xerces). This shouldn't be possible anymore, since in this solution the close method has been overridden in order to do nothing. So regardless of who is trying to close it, it simply should not get closed! By now I have another clue what it might could be. Since the patch does not allow closing the input stream, this input stream which is closed might not even pass this lines of code. Maybe those resources come from some other place. After some research I came across the following statement: There are two places that the application can deliver an input source to the parser: as the argument to the Parser.parse method, or as the return value of the *EntityResolver.resolveEntity* method. -- http://download.oracle.com/javase/6/docs/api/org/xml/sax/InputSource.html I am wondering if xerces gets the resource from EntityResolver.resolveEntity. This would explain a lot. So far I have found 3 implementations: * org.apache.xerces.util.DOMEntityResolverWrapper * org.apache.xerces.util.EntityResolverWrapper * org.apache.xerces.util.EntityResolver2Wrapper I am not sure yet which of those is involved here. Any comments, ideas, statements to this? Thanks. Gregor JARISCH Basis und Spezialdienste Raiffeisen Bausparkasse Gesellschaft m.b.H. 1050 Wien, Wiedner Hauptstraße 94 Tel.: +43 (1) 546 46-1619, Fax: DW 2360 E-Mail: gregor.jari...@raibau.at www.bausparen.at FN 116309v, Handelsgericht Wien - Jetzt Jugend Bausparen und Bausparbox holen! Alle Infos auf www.bausparen.at Von: Jakob Korherr jakob.korh...@gmail.com An: MyFaces Development dev@myfaces.apache.org Datum: 26.10.2011 12:59 Betreff: Re: java.lang.IllegalStateException: zip file closed Gesendet von: sethfromaust...@gmail.com Hi Gregor, This issue seems to be a race condition resulting of the combination of xerces closing every InputStream it gets and Jetty failing to handle this. In the stacktrace you can see that there is a call to ServletContext.getResource() via ExternalContext. Also you can see that it currently tries to load an xhtml file of a composite component. IMO the problem is the following: the 1st thread runs through the above stacktrace, Jetty opens the jar file in which the xhtml file is located and returns the URL. Then the second thread does the same. At the same time the 2nd thread does this, the first thread processes the xhtml file by getting the InputStream and handing it over to xerxes for parsing it (in order to create the component tree for the composite component). Unfortunately, xerxes closes this InputStream when it is done. However, the 2nd thread is still reading the same jar file (internally via the same JarInputStream), which unfortunately has been closed. Thus the exception from the JDK class. I think that this is a result of poor concurrent jar file handling of jetty. I don't know what the servlet spec states here exactly, but I am pretty sure that multiple concurrent connections to the same jar file should be possible. Regards, Jakob 2011/10/25 Michael Kurz michi.k...@gmx.at: Hi, have you already tried it on another servlet container like tomcat? I guess the key for finding out what happens is the other thread that does not fail. The first thing I would try to find out is where the JarFileResource (or the underlying file) is closed. Have you checked that the resource in question is really loaded with the code that was changed with the Jetty patch? regards Michael Am 25.10.2011 um 14:47 schrieb gregor.jari...@raibau.at: Hello, we are developing internal software based on myfaces (2.0.2) and jetty (7.1.6). We ran into the following problem: After the start of the server, if two requests (threads) are send at the same time, jetty reports an IllegalStateException: zip file closed. To me it seems that one request is closing the stream when it has
Re: [VOTE] Internal Incubator
+1 Regards, Jakob 2011/11/1 Gerhard Petracek gerhard.petra...@gmail.com: Hi, in order to check if there is a community for a new sub-project (esp. GSoC projects for MyFaces), we discussed [1] the introduction of an internal incubator. We would release such projects early and e.g. after a quarter we decide if we keep and promote a project (as a sub-project or a module of an existing sub-project) or if we drop it. Please vote: [+1] I like the idea [0] I'm not convinced but I'm ok with it [-1] I don't agree Regards, Gerhard [1] http://markmail.org/message/d7oogfabvliwn7fg -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] internal incubator
+1 Regards, Jakob 2011/10/28 Matt Benson gudnabr...@gmail.com: Guys, Just a note on the concept of a mini-incubator: been there, done that [1]. The basic available approaches are noted at [2] (search for Some possible solutions). Matt [1] http://markmail.org/message/n3t7lksceuplh45r [2] http://markmail.org/message/r6ffmmyh6pxnn6nd On Thu, Oct 27, 2011 at 4:32 PM, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Thursday, October 27, 2011 11:18 PM Subject: [DISCUSS] internal incubator hi @ all, this is a new thread based on [1]. the idea of an internal incubator: esp. gsoc projects (for myfaces) could move pretty easy to myfaces. as soon as we see that there is a community for it, we can promote such a project (as an own sub-project or as a module of an existing sub-project). after moving a project to this incubator, we shouldn't wait that long with the final discussion about keeping or dropping it (e.g. one quarter). potential candidates right now are: - codi-rad - html5components - manila regards, gerhard [1] http://mail-archives.apache.org/mod_mbox/myfaces-dev/201110.mbox/%3CCAGJtJfHBrOvO5m-isDvPSWODWkPKQjVfnsqK1rKYd%2BDEP5duzw%40mail.gmail.com%3E http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: treating obsolete code
+1 !! Regards, Jakob 2011/10/27 Bernd Bohmann bernd.bohm...@atanion.com: +1 for deleting Regards Bernd On Wed, Oct 26, 2011 at 6:08 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! I see a lot of commented out code which is many years old. I'm highly in favour to just delete code we don't need anymore! IF you only temporarily comment out something, then please mark it with /*X TODO some comment or //X TODO some comment otherwise comments must ONLY be used for one thing - commenting the code! LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: java.lang.IllegalStateException: zip file closed
(ScopedHandler.java:119) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:456) [org.eclipse.jetty.security_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358) [org.eclipse.jetty.servlet_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:866) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:245) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.Server.handle(Server.java:351) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1059) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:764) [org.eclipse.jetty.http_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:217) [org.eclipse.jetty.http_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424) [org.eclipse.jetty.server_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:506) [org.eclipse.jetty.io_7.1.6.v20100715.jar:7.1.6.v20100715] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436) [org.eclipse.jetty.util_7.1.6.v20100715.jar:7.1.6.v20100715] at java.lang.Thread.run(Thread.java:619) [na:1.6.0_17] Gregor JARISCH Basis und Spezialdienste Raiffeisen Bausparkasse Gesellschaft m.b.H. 1050 Wien, Wiedner Hauptstraße 94 Tel.: +43 (1) 546 46-1619, Fax: DW 2360 E-Mail: gregor.jari...@raibau.at www.bausparen.at FN 116309v, Handelsgericht Wien - Zuverlässigkeit seit 50 Jahren - Raiffeisen Bausparen Alle Infos auf https://www.bausparen.at/ mime-attachment.jpg __ Raiffeisen Bausparkasse Gesellschaft m.b.H., 1050 Wien, Wiedner Hauptstraße 94, Firmenbuchnummer 116309v, Handelsgericht Wien, DVR 0066257, UID ATU15350206 Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns unverzueglich zu informieren und sie zu loeschen. This e-mail message may contain information, which is confidential and protected. If you are not the intended recipient of this message, we ask you to inform us immediately and delete the message afterwards. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] how to get rid of tons of duplicated code
Hi Mark, +1 - that's exactly what I have been trying to accomplish some time ago (introducing common-shades [1]). Unfortunately, I was not successful back then. However, there is a slight problem with moving all this stuff into MyFaces shared, which I want to point out: code size. If we really put all the code that is shared across any MyFaces subproject into shared, it will get fat and ugly (even more than it is right now). In addition, if we continue including the whole shared project into MyFaces core, MyFaces core impl will get bigger and bigger. Thus I'd like to suggest something similar which I wanted to accomplish with common-shades: Introduce a new shared module, which consists of many submodules that each handle a specific functionality instead of being one fat module. With this approach each MyFaces subproject would be able to pick out only the stuff it really needs. Furthermore we would see more easily which code in shared is not used anymore (I guess at the moment there is a lot of it), just by checking which modules are still used in our poms. Regards, Jakob [1] https://svn.apache.org/repos/asf/myfaces/common-shades/ 2011/10/23 Mark Struberg strub...@yahoo.de: Hi! While working on the mafyces-commons cleanup I figured that we have tons of duplicated code spread over MyFaces. As an example I like to mention myfaces-commons-resourcehandler. There are 43 classes in total, and 35 of them are just 1:1 copied from other projects to provide resource management, zip, etc. For me this is an absolute no-go. Those classes have neither tests nor any documentation where they got forked from. Nor will any bug which gets fixed in another module make it's way over to all the other projects containing that very forked code. That's just ... unbelievable unmaintainable. There are 2 different ways to solve this (depending on the problem): A.) drop the functionality and provide a generalized solution. The GZIP of myfaces-commons-resourcehandleris an obvious example: We now copy this code over the 4th time or even more. Instead of doing this, we should rather do it in the classic unix fashion: do one thing, but do it well. Which means I'd rather see all the GZIP stuff factored out into an own mf-commons module as a Servlet Filter. This can then get applied to what ever other mechanism you like. This could also (commonly) cover cases like detecting http UserAgents which are not able to handle zipped resources, etc. That way we could provide this logic ONCE and have complete freedom over the configuration. B.) code reusable components once and use them in other projects (ev via shading it in). ClassLoaderResourceLoader would be a perfect candidate! I grepped through only the few pits which I have checked out locally and found this class 7 SEVEN times! I just can't believe that we can't move this stuff to a shared modul... Same for FacesServletMapping. 6 times copied around, WebConfigProviderFactory 5 times, ... There are whole packages with 10++ classes which got copied 1:1! I really could cry seeing this :( What can we do to solve this? Theoretically myfaces-shared should contain this stuff. This is exactly what it is for! Historically there have been some hand forged tweeks and ugly hacks, but nowadays we have the maven-shade-plugin to make our live easier. So the suggestion is: 1.) cleanup myfaces-shared. mf-shared has almost no checkstyle rules applied. 2.) add unit tests for myfaces-shared. Currently there are not many... 3.) move the shared code parts back to myfaces-shared and add unit tests. 4.) import myfaces-shared via maven dependency and use minimizeJar and relocations to package the stuff [+1] fine go ahead (ideally: yes, what parts can I help with?) [0] dont care [-1] wont work because ... I've attached a file which contains all Classes which name exists multiple times in MyFaces. The number is the cound how often they exist in MyFaces. I excluded current20. Please note that classes with the same name do not necessarily have the same content - but quite a lot actually do have! (scroll to the bottom of the file ...) LieGrue, strub -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [DISCUSS] how to get rid of tons of duplicated code
Ah, nice! I did not know that. Great stuff :) Regards, Jakob 2011/10/23 Mark Struberg strub...@yahoo.de: With this approach each MyFaces subproject would be able to pick out only the stuff it really needs. This is not needed if we use the maven-shade-plugin minimizeJar option [1] ! With minimizeJar enabled the dependency classes are analyzed and only the classes which really got used will get shaded into the destination jar. The only limitation is when some classes get loaded via Class.forName() or similar. But as long as there is a bytecode invocation it will work smoothly. Thus I really see no reason why we cannot use maven-shared these days! Thus also a formal +1 from me. LieGrue, strub [1] http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#minimizeJar - Original Message - From: Jakob Korherr jakob.korh...@gmail.com To: MyFaces Development dev@myfaces.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Sunday, October 23, 2011 12:00 PM Subject: Re: [DISCUSS] how to get rid of tons of duplicated code Hi Mark, +1 - that's exactly what I have been trying to accomplish some time ago (introducing common-shades [1]). Unfortunately, I was not successful back then. However, there is a slight problem with moving all this stuff into MyFaces shared, which I want to point out: code size. If we really put all the code that is shared across any MyFaces subproject into shared, it will get fat and ugly (even more than it is right now). In addition, if we continue including the whole shared project into MyFaces core, MyFaces core impl will get bigger and bigger. Thus I'd like to suggest something similar which I wanted to accomplish with common-shades: Introduce a new shared module, which consists of many submodules that each handle a specific functionality instead of being one fat module. With this approach each MyFaces subproject would be able to pick out only the stuff it really needs. Furthermore we would see more easily which code in shared is not used anymore (I guess at the moment there is a lot of it), just by checking which modules are still used in our poms. Regards, Jakob [1] https://svn.apache.org/repos/asf/myfaces/common-shades/ 2011/10/23 Mark Struberg strub...@yahoo.de: Hi! While working on the mafyces-commons cleanup I figured that we have tons of duplicated code spread over MyFaces. As an example I like to mention myfaces-commons-resourcehandler. There are 43 classes in total, and 35 of them are just 1:1 copied from other projects to provide resource management, zip, etc. For me this is an absolute no-go. Those classes have neither tests nor any documentation where they got forked from. Nor will any bug which gets fixed in another module make it's way over to all the other projects containing that very forked code. That's just ... unbelievable unmaintainable. There are 2 different ways to solve this (depending on the problem): A.) drop the functionality and provide a generalized solution. The GZIP of myfaces-commons-resourcehandleris an obvious example: We now copy this code over the 4th time or even more. Instead of doing this, we should rather do it in the classic unix fashion: do one thing, but do it well. Which means I'd rather see all the GZIP stuff factored out into an own mf-commons module as a Servlet Filter. This can then get applied to what ever other mechanism you like. This could also (commonly) cover cases like detecting http UserAgents which are not able to handle zipped resources, etc. That way we could provide this logic ONCE and have complete freedom over the configuration. B.) code reusable components once and use them in other projects (ev via shading it in). ClassLoaderResourceLoader would be a perfect candidate! I grepped through only the few pits which I have checked out locally and found this class 7 SEVEN times! I just can't believe that we can't move this stuff to a shared modul... Same for FacesServletMapping. 6 times copied around, WebConfigProviderFactory 5 times, ... There are whole packages with 10++ classes which got copied 1:1! I really could cry seeing this :( What can we do to solve this? Theoretically myfaces-shared should contain this stuff. This is exactly what it is for! Historically there have been some hand forged tweeks and ugly hacks, but nowadays we have the maven-shade-plugin to make our live easier. So the suggestion is: 1.) cleanup myfaces-shared. mf-shared has almost no checkstyle rules applied. 2.) add unit tests for myfaces-shared. Currently there are not many... 3.) move the shared code parts back to myfaces-shared and add unit tests. 4.) import myfaces-shared via maven dependency and use minimizeJar and relocations to package the stuff [+1] fine go ahead (ideally: yes, what parts can I help with?) [0] dont care [-1] wont work because ... I've
Re: gsoc/webtest vs gsoc/manila?
Hi,
Mhh why is the project not hosted on apache extras which would be the
perfect place for now?
Since there is no restriction for source code repositories from
Google, I left this choice to the student (Jan), and he preferred
assembla.com.
However, it would totally be fine to move it to myfaces/gsoc in the near future.
Regards,
Jakob
2011/10/20 Werner Punz werner.p...@gmail.com:
Mhh why is the project not hosted on apache extras which would be the
perfect place for now?
Werner
Am 10/20/11 9:41 AM, schrieb Gerhard Petracek:
hi mark,
manila is the next generation of myfaces webapp-test.
you already mentioned one of the restrictions/issues of myfaces
webapp-test and that's the reason why we don't have a release (with
manila everything would change in the release afterwards).
manila solves most of the known issues and should replace webapp-test
v1 as soon as we know that the approach of manila works in ci-servers.
imo we should test it before we move the code to apache, because it's
useless for us if there are basic issues (esp. in combination with
jenkins).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/20 Mark Struberg strub...@yahoo.de mailto:strub...@yahoo.de
Hi folks!
We now have 2 GSOC test projects which are based on Arquillian:
a.) gsoc/webtest [1] which got implemented last year and is already
in our SVN (but not yet released) and
b.) gsoc/manila [2] which is not yet granted to the ASF (or is it?)
What is the state of both projects?
If I understood them correctly both cover the same areas (at least
partly).
Oh yes, and having to write something like:
@WebappDependency.List
({
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.core:myfaces-extcdi-core-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-jsf20-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-api:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.myfaces.extensions.cdi.modules:myfaces-extcdi-message-module-impl:jar:1.0.2-SNAPSHOT),
@WebappDependency(org.apache.openwebbeans:openwebbeans-impl:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-spi:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-jsf:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-resource:jar:1.1.0),
@WebappDependency(org.apache.openwebbeans:openwebbeans-web:jar:1.1.0),
@WebappDependency(javassist:javassist:jar:3.12.0.GA
http://3.12.0.ga/),
@WebappDependency(net.sf.scannotation:scannotation:jar:1.0.2)
})
in a test Java class is an absolute no-go for me! This is terribly
to maintain and will way too often be broken...
Such things must NOT be part of any test class!
LieGrue,
strub
[1] https://svn.apache.org/repos/asf/myfaces/gsoc/webapptest
[2]http://subversion.assembla.com/svn/manila/trunk
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [DISCUSS] release CODI-1.0.2?
+1 Regards, Jakob 2011/10/17 Mark Struberg strub...@yahoo.de: Hi folks! We've done some fairly big improvements and new features since the release of CODI-1.0.2. So I think it's time to release CODI-1.0.2. For the release notes, please see [1]. The only issue which blocks us atm is the relase of MyFaces-parent-10. Leo, can we release the checkstyle-rules and myfaces-parent already? I've tested it with myfaces-core locally, should I commit the upgrade? Wdyt? LieGrue, strub [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311071version=12317614 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [COMMUNITY] MyFaces += Michael Kurz
Hi Michael, Congrats! Regards, Jakob 2011/9/30 Martin Marinschek mmarinsc...@apache.org: Hi Michael, congratulations! best regards, Martin On Fri, Sep 30, 2011 at 9:09 AM, Werner Punz werner.p...@gmail.com wrote: Am 9/30/11 8:11 AM, schrieb Gerhard Petracek: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Michael Kurz as the newest MyFaces committer! Michael is an active member of the MyFaces community, especially in MyFaces Core. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard Congratulations Michael, well deserved. werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
Hi, Both suggestions for a name are reasonable, because they suggest different things! What Leo suggested (STRICT_JSF_2_COMPATIBILITY), is the flag we (internally) have been discussing (and postponing) for a long time. This config parameter would enable us to include non-spec behavior in MyFaces core, which would make us fail the TCK, if we included it by default. However, by enabling it via config parameter only (STRICT_JSF_2_COMPATIBILITY=false), we would be able to fix obvious spec issues already in MyFaces core 2.0 (e.g. MYFACES-2552) and still passing the TCK. Thus we would not need to wait for the next spec release (which may not even contain the fix), to fix critical issues. What Mark and Bernd suggested is to include the fix for MYFACES-2552 and make a config parameter just for this behavior. Actually, I think introducing yet another config parameter for (in this case) very specific behavior is not the best idea, b/c no-one outside of the MyFaces developers will use it. Introducing a more generic config param, which would allow us to fix a lot more issues which are just like this one, is IMO a far better idea. Thus, my vote is +1 for STRICT_JSF_2_COMPATIBILITY and +0 for Bernd's suggestion. Regards, Jakob 2011/9/22 Martin Marinschek mmarinsc...@apache.org: +1 in general, +1 to Bernd's suggestion. best regards, Martin On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @bernd: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/9/22 Bernd Bohmann bernd.bohm...@atanion.com I agree STRICT_JSF_2_COMPATIBILITY is too generic. I think the param should contain EL, TYPE, MAP, RESOLVER, NULL. And it should enabled by default. Regards Bernd On Wed, Sep 21, 2011 at 11:50 PM, Mark Struberg strub...@yahoo.de wrote: Shouldnt the config contain the text EL_TYPE or so? We have far too many strict JSF spec flags already ;) LieGrue, strub - Original Message - From: Jakob Korherr jakob.korh...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: gudnabr...@gmail.com Sent: Wednesday, September 21, 2011 10:20 PM Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches +1 for including the fix in 2.0.x and 2.1.x + adding org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY Regards, Jakob 2011/9/21 Leonardo Uribe lu4...@gmail.com: Hi @Matt Benson: Could you attach at least the fragment with the solution for MYFACES-2552 ? so I can check it, create a patch for myfaces and write a page on: https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components with the explanation and the solution using a custom EL resolver. That would be very helpful. regards, Leonardo Uribe 2011/9/21 Leonardo Uribe lu4...@gmail.com: Hi It should be a param starting with org.apache.myfaces, like org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY The important part is that by default it should be disabled, to prevent receive over and over the same report. In theory, it is possible to write a custom EL resolver that check if the base object implements javax.faces.el.CompositeComponentExpressionHolder and if that so, do the required stuff only on getType(). So, if somebody is writing a composite component that relies on this behavior, it is possible to write the fix in a portable way to both Mojarra and MyFaces (thanks to CompositeComponentExpressionHolder). Note the change does not cause any side effects, because nobody relies on the wrong behavior, and what user wants is components work as expected. regards, Leonardo Uribe 2011/9/21 Mark Struberg strub...@yahoo.de: Not sure about that. Does the param start with javax.faces? In this case we should rather use an own internal one. Btw, if it's not in the spec even Mojarra would not be allowed to use a proprietary parameter with javax LieGrue, strub - Original Message - From: Matt Benson gudnabr...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Wednesday, September 21, 2011 6:29 PM Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches +1 However, let's simplify the context parameter by giving it a name relating to JSF 2.2 compatibility. I submitted the final implementation for Mojarra, so have every right to add the same to MyFaces. Matt On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 for it in combination with the context parameter regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/9/21 Rudy De
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+1 for including the fix in 2.0.x and 2.1.x + adding
org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY
Regards,
Jakob
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
@Matt Benson: Could you attach at least the fragment with the solution
for MYFACES-2552 ? so I can check it, create a patch for myfaces and
write a page on:
https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components
with the explanation and the solution using a custom EL resolver. That
would be very helpful.
regards,
Leonardo Uribe
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
It should be a param starting with org.apache.myfaces, like
org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY
The important part is that by default it should be disabled, to
prevent receive over and over the same report.
In theory, it is possible to write a custom EL resolver that check if
the base object implements
javax.faces.el.CompositeComponentExpressionHolder and if that so, do
the required stuff only on getType(). So, if somebody is writing a
composite component that relies on this behavior, it is possible to
write the fix in a portable way to both Mojarra and MyFaces (thanks to
CompositeComponentExpressionHolder).
Note the change does not cause any side effects, because nobody relies
on the wrong behavior, and what user wants is components work as
expected.
regards,
Leonardo Uribe
2011/9/21 Mark Struberg strub...@yahoo.de:
Not sure about that.
Does the param start with javax.faces? In this case we should rather use an
own internal one.
Btw, if it's not in the spec even Mojarra would not be allowed to use a
proprietary parameter with javax
LieGrue,
strub
- Original Message -
From: Matt Benson gudnabr...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Wednesday, September 21, 2011 6:29 PM
Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+1
However, let's simplify the context parameter by giving it a name
relating to JSF 2.2 compatibility. I submitted the final
implementation for Mojarra, so have every right to add the same to
MyFaces.
Matt
On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1 for it in combination with the context parameter
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/9/21 Rudy De Busscher rdebussc...@gmail.com
+1
And if we create a context parameter, it should behave by default as in
the JSF 2.2 Spec. If users want strict spec (2.0/2.1)behaviour they
have to
set the parameter value.
regards
Rudy
On 21 September 2011 17:08, Grant Smith work.gr...@gmail.com
wrote:
+1 if it's configurable in a context-param. How about
org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ?
On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz
michi.k...@gmx.at wrote:
+1
Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
+1
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
More than a year ago, it was found that EL expressions
like
#{cc.attrs.test} does not resolve its type correctly,
because the
composite component EL resolver is not able to find
the right type.
Instead, MapELResolver always return Object.class as
type, breaking
composite components that use h:selectOneXXX into its
internals. See
https://issues.apache.org/jira/browse/MYFACES-2552
The problem with this issue is we need to change the
way how
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver
works. JSF 2.0 spec clearly says in its section
5.6.2.2 that
getType()
for that EL resolver should return null.
The issue was reported to the EG and a fix was
included in JSF 2.2.
spec, see:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745
but we still receive reports about the same issue
(MYFACES-3311 and
others (last comment on MYFACES-1890) ).
So, the current behavior even if is described by the
spec is too
inconvenient. Note we already have some places in our
implementation
that does not follow strictly the spec, to keep things
working as
users expect. To follow the protocol in these cases,
we need an
official community decision about include it in 2.0.x
and 2.1.x
branches. Please vote:
+1 if you want this fix included in 2.0.x and 2.1.x.
+0
-1 and the reason why if you see this could cause any
problem.
regards,
Leonardo Uribe
[1]
http://www.apache.org/foundation/voting.html#ReleaseVotes
--
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.
--
Rudy De Busscher
http://www.c4j.be
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [DISCUSS] legal files in WARs like samples etc
+1 Regards, Jakob 2011/9/19 Mark Struberg strub...@yahoo.de: Hi folks! I'm pretty sure this doesn't only hit Trinidad but also a lot other projects, so I like to trigger a discussion on this very topic. Usually we only ship JAR files, and the code in apache-parent should make sure that each file properly contains LICENSE and NOTICE files. Of course such a mechanism doesn't exist for WAR files which we ship for samples and stuff. With shipping WAR files there are 2 problematic issues 1.) those must contain LICENSE and NOTICE files. See the mail below how to solve this. 2.) we might also 'distribute' (in a legal sense) 3-rd party JAR files inside of the WARs WEB-INF/lib directory! This is a bummer, and in OWB, we completely disabled the deployment of our samples via maven because of that! You can get the sources in the source-distribution.zip, you can build it yourself, etc. But we don't ship any 3rd party JARs which are not developed inside the ASF this way. Why is this problematic: OWB for example needs javassist which is MPL licensed. MPL is perfectly fine as dependency as a lot other CategoryA and CategoryB licensed projects are[1]. But MPL needs certain attribution when you _distribute_ the project! WDYT? Is this feasible or MyFaces too? LieGrue, strub [1] http://www.apache.org/legal/3party.html - Forwarded Message - From: Mark Struberg strub...@yahoo.de To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Monday, September 19, 2011 10:50 AM Subject: Re: [VOTE] Release of Trinidad 2.0.1 Hi Scott! I'm sorry, but I fear I have to veto with a -1. trinidad-components-showcase.war (WAR!) has no NOTICE nor LICENSE files I could find. I know we shipped lots of WAR files in the past without those, but I only recently became aware of this problem in OpenWebBeans where I had to re-roll my release too. This can easily get fixed by doing some packaging tricks Please see the maven-war-plugin config of the OWB samples https://svn.apache.org/repos/asf/openwebbeans/trunk/samples/pom.xml The important part is webResources resource directory./directory targetPathMETA-INF/targetPath includes includeLICENSE/include includeNOTICE/include /includes /resource /webResources Otherwise the release looks fine so far. txs LieGrue, strub - Original Message - From: Scott O'Bryan darkar...@gmail.com To: dev@myfaces.apache.org Cc: Sent: Saturday, September 17, 2011 2:38 AM Subject: [VOTE] Release of Trinidad 2.0.1 Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. Therefore, I would like to ask for a vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-072 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-072/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Resolved] (MYFACES-3306) h:selectManyCheckBox + JPA with Hibernate creates Hibernate PersistentCollection where it should not. Causes
[
https://issues.apache.org/jira/browse/MYFACES-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr resolved MYFACES-3306.
Resolution: Not A Problem
h:selectManyCheckBox + JPA with Hibernate creates Hibernate
PersistentCollection where it should not. Causes
---
Key: MYFACES-3306
URL: https://issues.apache.org/jira/browse/MYFACES-3306
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.2
Environment: JPA with Hibernate + Spring
Reporter: Kristian Jörg
Original Estimate: 24h
Remaining Estimate: 24h
I have a case where I use a JPA domain object (Mission) that has a standard
@ManyToMany relationship to another domain object Departments. The fetch type
is set to EAGER on both ends.
The web page has a h:selectManyCheckBox with all possible Departments. The
selection is then mapped to the mission object's department set via a custom
converter. This all works well.
When I submit my form I get an org.hibernate.LazyInitializationException in
(I believe) the validation phase. The problem is that MyFaces tries to
create a new instance of the specific hibernate class PersistentSet (which
should NOT be used outside Hibernate). It then populates this Set with
objects and that is when LazyInitializationException hits!
I have pinpointed the exact location to
org.apache.myfaces.shared_impl.renderkit.SharedRendererUtils.java, Line 255:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null
? componentValue.getClass()
: modelType).newInstance();
}
With I add a check so we are not instanciating Hibernate collections
(AbstractPersistentCollection) the program then goes on to create a standard
HashSet and all is well. My program works perfectly with this patch:
// try to create the (concrete) collection from
modelType
// or with the class object of componentValue (if
any)
try
{
targetForConvertedValues = (componentValue !=
null !(componentValue instanceof
org.hibernate.collection.AbstractPersistentCollection)
? componentValue.getClass()
: modelType).newInstance();
}
Of course, adding a dependency on Hibernate in Myfaces is not the correct
solution, so another solution has to be invented.
My program is solid in itself with regards to the dreaded LIE exception, it
is only when I use persisted objects with OneToMany or ManyToMany collections
that this problem occurs.
MyFaces should never try to instanciate Hibernate collections without having
an entity manager session, which you do not.
I can attach some code examples if needed, but the problem lies not in the
rather standard JSF code, but in this specific point in code listed above.
Let me know if more examples are needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release of myfaces core 2.1.3
+1 Regards, Jakob 2011/9/13 Werner Punz werner.p...@gmail.com: +1 Am 13.09.11 05:44, schrieb Leonardo Uribe: +1 2011/9/12 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() * [MYFACES-3301] - ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.3 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] https://repository.apache.org/content/repositories/orgapachemyfaces-055/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.9
+1 Regards, Jakob 2011/9/13 Werner Punz werner.p...@gmail.com: +1 Am 13.09.11 05:46, schrieb Leonardo Uribe: +1 2011/9/12 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.9 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() * [MYFACES-3301] - ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.0.9 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.9 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] https://repository.apache.org/content/repositories/orgapachemyfaces-054/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces209binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317644 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.3
Hi Werner, MYFACES-3300 is fixed in MYFACES-3301. Regards, Jakob 2011/9/9 Werner Punz werner.p...@gmail.com: Hi if we roll another release it probably might make sense to get the fix for MYFACES-3300 in as well. Werner Am 09.09.11 02:52, schrieb Leonardo Uribe: Hi Thanks Jakob for debug this one. It helps a lot. I'll send another vote soon with the artifacts updated, but first I want to check the code that cause this problem. Instead do a change on validate(), I think we should fix it in other way, in the contructor(s) of ContextAwareELException, because the spec could mention in a explicit way how to handle validator exceptions. regards, Leonardo Uribe 2011/9/8 Jakob Korherrjakob.korh...@gmail.com: Sorry Leo, but I have to change my vote to -1, because of MYFACES-3301. We cannot release two MyFaces versions with a broken ValidatorException handling mechanism! Regards, Jakob 2011/9/8 Jakob Korherrjakob.korh...@gmail.com: +1 Regards, Jakob 2011/9/7 Werner Punzwerner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.3 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] https://repository.apache.org/content/repositories/orgapachemyfaces-040/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.3
Hi, @Leo: OK, please add a patch to the issue. I am always open for a better solution! Regards, Jakob 2011/9/9 Jakob Korherr jakob.korh...@gmail.com: Hi Werner, MYFACES-3300 is fixed in MYFACES-3301. Regards, Jakob 2011/9/9 Werner Punz werner.p...@gmail.com: Hi if we roll another release it probably might make sense to get the fix for MYFACES-3300 in as well. Werner Am 09.09.11 02:52, schrieb Leonardo Uribe: Hi Thanks Jakob for debug this one. It helps a lot. I'll send another vote soon with the artifacts updated, but first I want to check the code that cause this problem. Instead do a change on validate(), I think we should fix it in other way, in the contructor(s) of ContextAwareELException, because the spec could mention in a explicit way how to handle validator exceptions. regards, Leonardo Uribe 2011/9/8 Jakob Korherrjakob.korh...@gmail.com: Sorry Leo, but I have to change my vote to -1, because of MYFACES-3301. We cannot release two MyFaces versions with a broken ValidatorException handling mechanism! Regards, Jakob 2011/9/8 Jakob Korherrjakob.korh...@gmail.com: +1 Regards, Jakob 2011/9/7 Werner Punzwerner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.3 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] https://repository.apache.org/content/repositories/orgapachemyfaces-040/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.9
+1 Regards, Jakob 2011/9/7 Werner Punz werner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.9 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.0.9 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.9 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] https://repository.apache.org/content/repositories/orgapachemyfaces-038/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces209binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317644 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.3
+1 Regards, Jakob 2011/9/7 Werner Punz werner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.3 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] https://repository.apache.org/content/repositories/orgapachemyfaces-040/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
[ https://issues.apache.org/jira/browse/MYFACES-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100140#comment-13100140 ] Jakob Korherr commented on MYFACES-3300: Hi Michi, Here are the 2.1.2 release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316512 Could you provide an example-war that shows the problem? I am wondering if we should stop the 2.1.3 release, b/c of this issue. WDYT? Regards, Jakob Ajax behavior change from 2.1.1 to 2.1.2 Key: MYFACES-3300 URL: https://issues.apache.org/jira/browse/MYFACES-3300 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Michael Kurz I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved. With 2.1.2 I have two issues: 1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again. 2) Now validation kicks in for invalid values and I get an error message in the browser This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1). Would be interesting to know what really changed here! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
[ https://issues.apache.org/jira/browse/MYFACES-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100147#comment-13100147 ] Jakob Korherr commented on MYFACES-3300: OK, thanks for the example. I'll take a look at it! Ajax behavior change from 2.1.1 to 2.1.2 Key: MYFACES-3300 URL: https://issues.apache.org/jira/browse/MYFACES-3300 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Michael Kurz Attachments: MYFACES-3300-test.zip I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved. With 2.1.2 I have two issues: 1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again. 2) Now validation kicks in for invalid values and I get an error message in the browser This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1). Would be interesting to know what really changed here! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
[
https://issues.apache.org/jira/browse/MYFACES-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100174#comment-13100174
]
Jakob Korherr commented on MYFACES-3300:
Hi Michi,
I found the bug. The problem originates from the new ContextAware exception
reporting system in MyFaces: In MethodExpressionValidator.validate() the
validator gets called in a try {} catch (ELException) {} block, and in the
catch block the caught ELException is checked if it was caused by a
ValidatorException. In MyFaces 2.1.1 (and before) this was true, b/c it was an
ELException which was caused by a ValidatorException. Now, due to the exception
reporting system, it is a ContextAwareELException which was caused by an
ELException which was caused by a ValidatorException. Thus the check fails and
the ValidatorException is not handled as a validation error, but as an
ELException, and thus the error.
Fortunately, in your case there is an easy fix, which I'd recommend anyway: use
immediate=true on the h:selectBooleanCheckbox! This will move the
ValueChangeEvent to the end of phase 2 and thus the validator won't even be
called and the state will also not be lost, b/c the submitted values have
already been applied.
If you check your example again with MyFaces 2.1.1 (and before), you will see
that without immediate=true on the h:selectBooleanCheckbox you will also see
the error there, however not on the browser via javascript alert, but in the
server log as unhandled FacesMessage (which was created by the properly handled
ValidationException), looking like this:
WARNUNG: There are some unhandled FacesMessages, this means not every
FacesMessage had a chance to be rendered.
These unhandled FacesMessages are:
- Kreditkartennummer muss aus 4 Ziffern bestehen.
Thanks a lot for reporting this! It tells us that the validation via the
validator= attribute is totally broken in MyFaces 2.1.2. This is a
dealbreaker for the 2.1.3 release.
Ajax behavior change from 2.1.1 to 2.1.2
Key: MYFACES-3300
URL: https://issues.apache.org/jira/browse/MYFACES-3300
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.2
Reporter: Michael Kurz
Assignee: Jakob Korherr
Attachments: MYFACES-3300-test.zip
I am currently trying to update some examples to Myfaces 2.1.2 and ran into
some ajax related problems. I have a h:selectBooleanCheckbox component that
collapses and expands two input fields via f:ajax. There is a value change
listener for the checkbox that sets the value internally and calls
renderResponse(). In f:ajax, those input fields are also listed in execute to
preserve the input the user has potentially made. So far, I had no problems
with this solution. The validation for the input fields did not kick in (or
did not bother me) and the values were preserved.
With 2.1.2 I have two issues:
1) Even if the input values are valid the values in the input fields vanish
when they are expanded and collapsed again.
2) Now validation kicks in for invalid values and I get an error message in
the browser
This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1).
Would be interesting to know what really changed here!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3301) ValidatorExceptions are not properly handled in MethodExpressionValidator.validate()
ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() Key: MYFACES-3301 URL: https://issues.apache.org/jira/browse/MYFACES-3301 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Blocker Due to the new ContextAware exception reporting system, ValidatorExceptions are not handled as validation errors, but as ELExceptions. See MYFACES-3300 for a detailed description and an example. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release of myfaces core 2.1.3
Sorry Leo, but I have to change my vote to -1, because of MYFACES-3301. We cannot release two MyFaces versions with a broken ValidatorException handling mechanism! Regards, Jakob 2011/9/8 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2011/9/7 Werner Punz werner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.3 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.3 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.3 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] https://repository.apache.org/content/repositories/orgapachemyfaces-040/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces213binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317642 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.9
Sorry Leo, but I have to change my vote to -1, because of MYFACES-3301. We cannot release two MyFaces versions with a broken ValidatorException handling mechanism! Regards, Jakob 2011/9/8 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2011/9/7 Werner Punz werner.p...@gmail.com: +1 Am 07.09.11 09:18, schrieb Leonardo Uribe: +1 2011/9/6 Leonardo Uribelu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.9 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3294] - REGRESSION: 2.0.7-2.0.8: Facets lost after validation error POST-back * [MYFACES-3298] - h:outputText incorectly renders an extraspan * [MYFACES-3291] - jsf.js make the comments and structures jsdoc toolkit friendly * [MYFACES-3295] - Replace RendererUtils.renderChild() by UIComponent.encodeAll() The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.0.9 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.9 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] https://repository.apache.org/content/repositories/orgapachemyfaces-038/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces209binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12317644 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Resolved] (MYFACES-3300) Ajax behavior change from 2.1.1 to 2.1.2
[ https://issues.apache.org/jira/browse/MYFACES-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-3300. Resolution: Fixed Fix Version/s: 2.1.4-SNAPSHOT 2.0.10-SNAPSHOT fix committed on MYFACES-3301 Ajax behavior change from 2.1.1 to 2.1.2 Key: MYFACES-3300 URL: https://issues.apache.org/jira/browse/MYFACES-3300 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Reporter: Michael Kurz Assignee: Jakob Korherr Fix For: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT Attachments: MYFACES-3300-test.zip I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved. With 2.1.2 I have two issues: 1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again. 2) Now validation kicks in for invalid values and I get an error message in the browser This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1). Would be interesting to know what really changed here! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3301) ValidatorExceptions are not properly handled in MethodExpressionValidator.validate()
[ https://issues.apache.org/jira/browse/MYFACES-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-3301. Resolution: Fixed Fix Version/s: 2.1.4-SNAPSHOT 2.0.10-SNAPSHOT fixed ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() Key: MYFACES-3301 URL: https://issues.apache.org/jira/browse/MYFACES-3301 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.8, 2.1.2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Blocker Fix For: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT Due to the new ContextAware exception reporting system, ValidatorExceptions are not handled as validation errors, but as ELExceptions. See MYFACES-3300 for a detailed description and an example. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3301) ValidatorExceptions are not properly handled in MethodExpressionValidator.validate()
[ https://issues.apache.org/jira/browse/MYFACES-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100194#comment-13100194 ] Jakob Korherr commented on MYFACES-3301: The changes also need to be applied to _ComponentUtils.callValidators(), because since we have a MethodExpressionToMethodBinding mechanism the new ELException wrapper will also effect this area. ValidatorExceptions are not properly handled in MethodExpressionValidator.validate() Key: MYFACES-3301 URL: https://issues.apache.org/jira/browse/MYFACES-3301 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.8, 2.1.2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Blocker Fix For: 2.0.10-SNAPSHOT, 2.1.4-SNAPSHOT Due to the new ContextAware exception reporting system, ValidatorExceptions are not handled as validation errors, but as ELExceptions. See MYFACES-3300 for a detailed description and an example. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release of myfaces jsdoc plugin 1.0-beta-1
+1 Regards, Jakob 2011/9/3 Mark Struberg strub...@yahoo.de: cool! +1 LieGrue, strub From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Friday, September 2, 2011 7:25 PM Subject: [VOTE] release of myfaces jsdoc plugin 1.0-beta-1 Hi, I was running the needed tasks to get the 1.0-beta-1 release of Apache MyFaces JSDoc Plugin out. This plugin will be used to generate the jsdoc of MyFaces Core 2.0.x/2.1.x. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-jsdoc-plugin v1.0-beta-1 [1] The artifacts were deployed to a nexus repository ([1]). Please take a look at the 1.0-beta-1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +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] https://repository.apache.org/content/repositories/orgapachemyfaces-020/org/apache/myfaces/buildtools/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/buildtools/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.0.8
+1 Regards, Jakob 2011/8/24 Leonardo Uribe lu4...@gmail.com: +1 2011/8/23 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.0.8 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.9 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.8 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.8 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] https://repository.apache.org/content/repositories/orgapachemyfaces-061/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces208binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316514 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Updated] (MYFACES-3051) Use multiple ClassLoaders to find resources (not only ContextClassLoader)
[ https://issues.apache.org/jira/browse/MYFACES-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-3051: --- Resolution: Won't Fix Status: Resolved (was: Patch Available) Use multiple ClassLoaders to find resources (not only ContextClassLoader) - Key: MYFACES-3051 URL: https://issues.apache.org/jira/browse/MYFACES-3051 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.4 Environment: OSGi Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-3051-first-draft.patch, MYFACES-3051-impl-and-shared-2.patch, MYFACES-3051-impl-and-shared.patch In most parts of the code we only use the ContextClassLoader to find Classes and Resources. However, in some parts we also use the ClassLoader of the current Class or of a specific Class (e.g. to use myfaces-api and/or myfaces-impl ClassLoader, see ApplicationImpl.getResourceBundle(), BeanValidator.postSetValidationGroups(), ResourceHandlerImpl.getBundle() or FactoryFinder for example). IMO we should unify this code and maybe provide a custom ClassLoader that encapsulates three ClassLoaders (ContextClassLoader, myfaces-api and myfaces-impl). This most certainly would solve a lot of OSGi related problems. WDYT? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3290) Archetype for integration-test modules
Archetype for integration-test modules -- Key: MYFACES-3290 URL: https://issues.apache.org/jira/browse/MYFACES-3290 Project: MyFaces Core Issue Type: New Feature Components: Archetype Reporter: Jakob Korherr Assignee: Jakob Korherr We should provide an archetype for generating integration-test modules. This will make creating an integration-test a lot easier! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[core] Integration tests archetype (was: svn commit: r1161089 - in /myfaces/myfaces-build-tools/trunk/maven2-archetypes: ...)
and el 2.2 + + * issueId is the issue-id of the JIRA issue which this integration test addresses + + [] + + The version of the project is automatically set to a default value (e.g. 2.0.9-SNAPSHOT). If you + want to test a different version, you have to change this manually in the pom.xml. Modified: myfaces/myfaces-build-tools/trunk/maven2-archetypes/pom.xml URL: http://svn.apache.org/viewvc/myfaces/myfaces-build-tools/trunk/maven2-archetypes/pom.xml?rev=1161089r1=1161088r2=1161089view=diff == --- myfaces/myfaces-build-tools/trunk/maven2-archetypes/pom.xml (original) +++ myfaces/myfaces-build-tools/trunk/maven2-archetypes/pom.xml Wed Aug 24 13:19:38 2011 @@ -121,6 +121,7 @@ modulemyfaces-archetype-jsfcomponents20/module modulemyfaces-archetype-codi-jsf12/module modulemyfaces-archetype-codi-jsf20/module + modulemyfaces-archetype-core-integration-test/module /modules distributionManagement -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3290) Archetype for integration-test modules
[ https://issues.apache.org/jira/browse/MYFACES-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090204#comment-13090204 ] Jakob Korherr commented on MYFACES-3290: committed first draft. This will certainly change a bit, after the integration-test module has been re-designed. Archetype for integration-test modules -- Key: MYFACES-3290 URL: https://issues.apache.org/jira/browse/MYFACES-3290 Project: MyFaces Core Issue Type: New Feature Components: Archetype Reporter: Jakob Korherr Assignee: Jakob Korherr We should provide an archetype for generating integration-test modules. This will make creating an integration-test a lot easier! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] Integration tests archetype (was: svn commit: r1161089 - in /myfaces/myfaces-build-tools/trunk/maven2-archetypes: ...)
And of course, we should also keep Jan's GSoC project Manila in mind, which is soon finished! Regards, Jakob 2011/8/24 Jakob Korherr jak...@apache.org: Hi guys, I just committed an archetype for creating an integration-test module for MyFaces core. With this archetype you are able to generate a module with one of three configurations (servlet 2.5 + el 1.0, servlet 2.5 + el 2.2 or serlvet 3.0 + el 2.2), just like the basic integration-tests modules in the 2.0.x branch. This stuff works pretty well, however while working on the archetype I was - again - thinking about the basic integration-test architecture for MyFaces core and I found some flaws in the current design. For example it is not possible to test MyFaces core 2.0.7-SNAPSHOT or earlier, b/c there was no integration-test support module back then. Or the version of MyFaces core is currently only defined by the parent module, which is pretty inflexible. And of course there is also the discussion about re-using some tests across different versions, which is not easily possible at the moment. Thus I am thinking of changing the integration-test module structure a bit, which would of course also mean changing the archetype. So please see this archetype as a first draft and nothing more! Suggestions for a kick-ass integration-test module structure are always welcome! Thanks for your attention. Regards, Jakob -- Forwarded message -- From: jak...@apache.org Date: 2011/8/24 Subject: svn commit: r1161089 - in /myfaces/myfaces-build-tools/trunk/maven2-archetypes: ./ myfaces-archetype-codi-jsf12/src/site/apt/ myfaces-archetype-codi-jsf20/src/site/apt/ myfaces-archetype-core-integration-test/ myfaces-archetype-core-integration-test/sr... To: comm...@myfaces.apache.org Author: jakobk Date: Wed Aug 24 13:19:38 2011 New Revision: 1161089 URL: http://svn.apache.org/viewvc?rev=1161089view=rev Log: MYFACES-3290 Archetype for integration-test modules Added: myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/ (with props) myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/pom.xml myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/META-INF/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/META-INF/LICENSE.txt - copied unchanged from r1146098, myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-codi-jsf20/src/main/resources/META-INF/LICENSE.txt myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/META-INF/NOTICE.txt - copied unchanged from r1146098, myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-codi-jsf20/src/main/resources/META-INF/NOTICE.txt myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/META-INF/maven/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/META-INF/maven/archetype-metadata.xml myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/pom.xml myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/java/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/java/TestBean.java myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/webapp/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/ myfaces/myfaces-build-tools/trunk/maven2-archetypes/myfaces-archetype-core-integration-test/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/web.xml myfaces/myfaces-build-tools/trunk/maven2-archetypes
Re: Any plan for releasing MyFaces 2.0.8 ?
Hi, Yes, Leonardo will start the release procedure soon! Regards, Jakob 2011/8/23 Ivan xhh...@gmail.com: Hi, I found MyFaces community is voting for some components. is the 2.0.8 on the schedule now ? 2011/7/26 Leonardo Uribe lu4...@gmail.com Hi Maybe a release will occur at the middle of next month. Let's see what happen. regards, Leonardo Uribe 2011/7/25 Ivan xhh...@gmail.com: Hi, MyFaces devs, any plan for releasing MyFaces 2.0.8 ? We hope to use that version in the coming Geronimo 3.0. Thanks. -- Ivan -- Ivan -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces core 2.1.2
+1 Regards, Jakob 2011/8/23 Leonardo Uribe lu4...@gmail.com: +1 2011/8/22 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.2 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.2 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.1.2 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] https://repository.apache.org/content/repositories/orgapachemyfaces-057/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces212binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316512 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces test 1.0.4
Hi Leo, Actually I would really like to see MYFACESTEST-56 (JSF 2.1 mock support) fixed, before the next release, but I don't want to block the release(s) of MyFaces core.. Thus my vote is +0. Regards, Jakob 2011/8/17 Leonardo Uribe lu4...@gmail.com: +1 2011/8/17 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.4 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of myfaces core 2.0.8 and 2.1.2. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.4 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.4 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] https://repository.apache.org/content/repositories/orgapachemyfaces-046/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest104binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12317607 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Spec issue for handling of custom validator tag attributes in wrapping mode
Hi Matt, Will do ;) Regards, Jakob 2011/8/16 Matt Benson gudnabr...@gmail.com: (@Jakob) Can we escalate to the EG? http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 Thanks, Matt -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [COMMUNITY] MyFaces += Matt Benson
Welcome, Matt! Regards, Jakob 2011/8/16 Gerhard Petracek gpetra...@apache.org: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Matt Benson as the newest MyFaces committer! Matt is an active member of the MyFaces community, especially in MyFaces Core and MyFaces Extensions Validator. @Matt: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [myfaces] Site and documentation improvements
+1 Regards, Jakob 2011/8/10 Bernd Bohmann bernd.bohm...@googlemail.com: +1 please deploy it On Wed, Aug 10, 2011 at 8:26 AM, 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 2011/8/10 Leonardo Uribe lu4...@gmail.com Hi Just FYI, following the discussion some months ago about enhance myfaces site and create a proper wiki documentation, I have started to move and organize the documentation from our old wiki: http://wiki.apache.org/myfaces/ Into the new confluence wiki, used intensively for other projects like extval or codi: https://cwiki.apache.org/confluence/display/MYFACES The idea on the following days is do some changes to myfaces site layout. There is a screenshot of how the left panel of myfaces main site will change on: https://issues.apache.org/jira/browse/MYFACES-3273 This is a good moment to propose your ideas about how enhance myfaces documentation. The idea is continue the work done by Bart Kummel in our wiki page and integrate it. The intention is focus on: 1. Better site layout. 2. Move create and update wiki pages. 3. Enhance myfaces-builder-plugin documentation generation. Suggestions are welcome. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: custom implicit objects
implementation, i'm not sure if we really get more
performance with such a spi.
(mark also implemented a cache for methods which aren't
intercepted. i
already tested it and depending on the constellation the
increase in
performance is about 5%.)
regards,
gerhard
[1]
http://os890.blogspot.com/2011/08/benchmark-boost-myfaces-codi-scopes.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Hi,
if user uses plain old JSF style with managed beans
like:
#{sessionScope.mySessionScopedBean} or
#{requestScope.myRequestScopedBean} or
#{requestScope.varFromDataTable.property}
it can achieve excellent performance during render
response
phase,
because every EL resolution takes only two steps:
1) o.a.m.ImplicitObjectResolver resolves
sessionScope or
requestScope to
java.util.Map
2) javax.el.MapELResolver reads
map.get(mySessionScopedBean)
and sets
elContext.setPropertyResolved
(at first access ManagedBeanResolver must create
bean instance
but we
can ignore it for simplicity).
Specially if user uses EL resolvers ordering [1]
and creates
chain of
(ImlicitObjectResolver,MapELResolver, other
resolvers) then
resolving
takes only two first resolvers.
Now compare it with situation where CDI is used.
Because
CDI/OWB
resolver is not so fast as default el resolvers,
common usage
is put it
at bottom of resolvers chain with
OpenWebBeansELResolverComparator. Then
resolving must go thru all ELresolvers in chain (12
or more
resolvers)
to find a @Named bean.
How to improve this? One thing can be use custom
implicit
object for
this
1) create ImplicitObjectsProvider SPI interface in
myfaces
2) CDI and CDI extension will add own implementation
of
myfaces
ImlicitObject, for example #{codiWindowScope} from
CODI
3) the resolved value from implicit object can mimic
the map
interfaces
(for example WindowScopeMap) to preserve behaviour
of servlet
scopes and
to use MapELResolver
WDYT? Any other ideas?
Regards,
Kočičák
[1]
https://cwiki.apache.org/MYFACES/elresolver-ordering.html
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] dynamic script before /body (an equivalent for DialogRequest from Trinidad)
Hi, Nope, I don't think so. Maybe you can achieve it via a javascript event-handler on the client, but I actually don't know for sure. Maybe Werner can help you out! Regards, Jakob 2011/8/2 Martin Koci martin.kocicak.k...@gmail.com: Hi, has JSF an official API to achieve similar functionality as [1] ? Purpose and use case: 1) JSF process partially view 2) JSF artifact creates and queues a request render this script ... before /body 3) new element script is created and rendered before /body this is not same same @Resource(target=body). Also this must work with partial response wihout explicit render=@all Any ideas? Thanks, Kočičák [1] https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/DialogRequest.java -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] steps to release myfaces core 2.1.2 / 2.0.8
Hi Leo, Thanks for the heads up! Regards, Jakob 2011/8/2 Leonardo Uribe lu4...@gmail.com: Hi I think it is a good moment to do another release of myfaces core 2.1.2 / 2.0.8. The idea is propose a vote in 1 or 2 week, so if you have a bug (not improvement) that requires to be solved, this is a good moment to say it. The only issue left for a release is this one: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028 that will be done in the next days. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] move or add integration tests to myfaces 2.1.x (now trunk)
Hi, The reasons I put the integration tests module as a submodule directly into myfaces core was that 1) if you checkout core, you get the whole integration-testing stuff too (like in every maven-plugin project where the integration-tests are in src/it/) 2) the sub-module can be added via profile and thus has no impact on normal builds and the release procedure (b/c it does not need to be released) 3) it's very easy to run a build and execute the integration-tests (just one maven command) 4) in your IDE, the integration-test webapps will automatically be runnable (without any further configuration) and thus be easy to debug Unfortunately, this solution does not fix the problem of running some integration-tests for multiple versions (as you guys pointed out). We (I) need to look into that, but I would really like to keep this stuff as a submodule of core. Regards, Jakob 2011/7/29 Gerhard Petracek gerhard.petra...@gmail.com: imo we should keep it simple. #1 it should be as simple as possible to execute the tests #2 tests for the jsf api should be executed with the first possible version as well as all later versions (e.g. 2.0.2 - 2.1.0+ - 2.2.0+ ...). a solution which meets both will get my +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/29 Leonardo Uribe lu4...@gmail.com Hi I think there are many ways to do it. For example, you can play with source paths and maven profiles. For example the following code is valid: profiles profile idtests-jsf-21/id activation property namejsf/name value21/value /property /activation build plugins plugin artifactIdmaven-war-plugin/artifactId configuration webResources resource directorysrc/main/webapp21/directory /resource /webResources /configuration /plugin /plugins /build /profile You can include source, resource, or webappp directories based on a profile. We can do trick about run in for jsf 2.0, create an specific task for hudson and playing with the profiles. Note we don't need to generate any artifacts or even release them. The only thing we need is run them periodically. The problem about have the code in different locations is the same we had with shared module: to compile one we need compile the other one. That's other reason why I'm proposing move everything instead keep two copies. regards, Leonardo 2011/7/29 Gerhard Petracek gerhard.petra...@gmail.com: @jakob: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/29 Jakob Korherr jakob.korh...@gmail.com Hi, I would like to do it exactly like we did it in MyFaces-Test, however not exactly like you're proposing. As you said, MyFaces-Test keeps the most code in the 1.2 module and the 2.0 module just takes what it needs. But what you're proposing is to move all integration-tests to 2.1 and also run it with 2.0 in some kind of way.. I would like to have the 2.0 integration-tests really in the 2.0 branch. If some of them (or as you pointed out: most of them) also apply to the 2.1 branch, the 2.1 branch should re-use them dynamically and not the other way round. Thus it would be like this: 2.0 branch provides all 2.0 applicable tests, 2.1 branch re-uses the tests which also apply for 2.1 and adds some 2.1 specific ones. Regards, Jakob 2011/7/28 Leonardo Uribe lu4...@gmail.com: Hi Some weeks ago a new module for integration test was added. See. https://issues.apache.org/jira/browse/MYFACES-3217 The code proposed was committed on 2.0.x branch. In the following mail we'll discuss if we should move this to current trunk (2.1.x) or create and maintain two copies: one in 2.0.x and the other one in 2.1.x (trunk). I agree that both branches are still used a lot and are being maintained actively. But I think maintain two branches of the same testing code seems to be an unnecessary burden. I think we can put this in just one place an make it run with 2.0. / 2.1 with just some maven configuration. Note 2.0.x and 2.1.x are very similar. In practice, every time we found an issue in 2.1.x, the same patch is applied to 2.0.x too. So it is not necessary to run the integration tests for 2.0.x branch because in practice when we run it against 2.1.x, we are taking into account 2.0.x, as long as the changes be commited on 2.0.x too. In few words, put this on trunk does not mean it will not run against 2.0 . A light way to deal with this kind of problem is take a look
Re: [core] dynamic script before /body (an equivalent for DialogRequest from Trinidad)
Hi, Maybe you can override BodyRenderer to implement this. For normal request: sure. For AJAX requests: whole body re-rendering would be necessary, thus not really usable. Regards, Jakob 2011/8/3 Çağatay Çivici cagatay.civ...@gmail.com: Maybe you can override BodyRenderer to implement this. On Aug 3, 2011, at 11:39 AM, Jakob Korherr wrote: Hi, Nope, I don't think so. Maybe you can achieve it via a javascript event-handler on the client, but I actually don't know for sure. Maybe Werner can help you out! Regards, Jakob 2011/8/2 Martin Koci martin.kocicak.k...@gmail.com: Hi, has JSF an official API to achieve similar functionality as [1] ? Purpose and use case: 1) JSF process partially view 2) JSF artifact creates and queues a request render this script ... before /body 3) new element script is created and rendered before /body this is not same same @Resource(target=body). Also this must work with partial response wihout explicit render=@all Any ideas? Thanks, Kočičák [1] https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/DialogRequest.java -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at Çağatay Çivici Principal Consultant PrimeFaces Lead | JSF EG Member Prime Teknoloji Bilkent Cyberpark, A-303d 06800 Ankara/Turkey Tel: +90 312 265 05 07 http://www.prime.com.tr -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
common JSF (spec) problems/issues wiki page (was: An issue with converts and JSF2.0 CompositeComponents)
Hi guys,
(moving to dev-list)
Sven has a point. It would be nice to have a wiki page describing
common JSF (spec) problems/issues and workarounds for them.
WDYT?
Regards,
Jakob
-- Forwarded message --
From: S. Bunge sbung...@nnga.de
Date: 2011/7/28
Subject: Re: An issue with converts and JSF2.0 CompositeComponents
To: MyFaces Discussion us...@myfaces.apache.org
Hey Matt,
thanks for your help and your hint to an additional ELResolver. I've
already thought that is a little gap in the spec. Maybe this could be
added to the wiki-page because without your fix the CC-feature is not
(really) usable in JSF2.0/2.1 I think.
Best regards,
Sven
Am 27.07.2011 20:10, schrieb Matt Benson:
Hi,
This looks like https://issues.apache.org/jira/browse/MYFACES-2552
where I have noted my workaround.
HTH,
Matt
On Wed, Jul 27, 2011 at 1:00 PM, S. Bungesbung...@nnga.de wrote:
Hi all,
I got an issue using the composite components feature of jsf2.0.
It's quite possible that I'm using the feature the wrong way.
I created such component to combine a label and an h:inputText. If I use
it with string objects all works fine but when I start to use instances of
custom classes and a converter registered in the faces-config.xml must
handle the object, it fails.
I use MyFaces 2.0.7 with a tomcat 6.0.32. I removed the label and other
stuff in my example:
My custom component (cc-ns: http://java.sun.com/jsf/composite;)
...
cc:interface
cc:attribute name=id required=true /
cc:attribute name=value required=true /
/cc:interface
cc:implementation
h:inputText id=inputText value=#{cc.attrs.value} /
/cc:implementation
...
I named the file 'myCC.xhtml' in /resources/myComponents/ so I can use it
with ns-declaration:
'xmlns:my=http://java.sun.com/jsf/composite/myComponents;' in my facelets.
I created also a bean named 'helloWorldBacking' with getMuh/setMuh and it
returns an Object of Type 'Muh'. A converter is registered in the
faces-config with 'converter-for-class' to handle the conversation between
view and model for the type.
If I useh:inputText id=abc value=#{helloWorldBacking.muh} /
directly in my facelet it works like a charm. The converter is called and
get/set is called with the right object in the update model phase. But if I
switch to the myCC-component I get an exception:
Caused by: javax.el.ELException: /resources/myComponents/myCC.xhtml at
line 17 and column 62 value=#{cc.attrs.value}:
/helloWorld.xhtml at line 17 and column 71
value=#{helloWorldBacking.muh}: Cannot convert asdfasd of type class
java.lang.String to class elproblem.Muh
at
org.apache.myfaces.view.facelets.el.TagValueExpression.setValue(TagValueExpression.java:129)
at
org.apache.myfaces.view.facelets.el.LocationValueExpression.setValue(LocationValueExpression.java:120)
at javax.faces.component.UIInput.updateModel(UIInput.java:379)
Maybe the behavior is slightly different with the used EL-library (I tried
jasper-el of the tomcat and EL2.2 of the glassfish) -- 'sometimes' it works
with none-null values the right way but if the bean returns 'null' if fails
every time.
My investigations came to a stop at following point:
_SharedRendererUtils#findUIOutputConverter doesn't get the outer value
binding of the composite component and can't determine the type. So no
converter is called and he tried to update
the model with a String.
If I set the type to the cc:attribute it doesn't work. That would be a bad
solution anyway because the composite component must be abstract
(otherwise I could call the right converter by id :-) )
So my questions: Do I use the composite components feature the right
way? If not: What is my fault? What are your suggestions?
Thanks for your help,
Sven
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] move or add integration tests to myfaces 2.1.x (now trunk)
Hi, I would like to do it exactly like we did it in MyFaces-Test, however not exactly like you're proposing. As you said, MyFaces-Test keeps the most code in the 1.2 module and the 2.0 module just takes what it needs. But what you're proposing is to move all integration-tests to 2.1 and also run it with 2.0 in some kind of way.. I would like to have the 2.0 integration-tests really in the 2.0 branch. If some of them (or as you pointed out: most of them) also apply to the 2.1 branch, the 2.1 branch should re-use them dynamically and not the other way round. Thus it would be like this: 2.0 branch provides all 2.0 applicable tests, 2.1 branch re-uses the tests which also apply for 2.1 and adds some 2.1 specific ones. Regards, Jakob 2011/7/28 Leonardo Uribe lu4...@gmail.com: Hi Some weeks ago a new module for integration test was added. See. https://issues.apache.org/jira/browse/MYFACES-3217 The code proposed was committed on 2.0.x branch. In the following mail we'll discuss if we should move this to current trunk (2.1.x) or create and maintain two copies: one in 2.0.x and the other one in 2.1.x (trunk). I agree that both branches are still used a lot and are being maintained actively. But I think maintain two branches of the same testing code seems to be an unnecessary burden. I think we can put this in just one place an make it run with 2.0. / 2.1 with just some maven configuration. Note 2.0.x and 2.1.x are very similar. In practice, every time we found an issue in 2.1.x, the same patch is applied to 2.0.x too. So it is not necessary to run the integration tests for 2.0.x branch because in practice when we run it against 2.1.x, we are taking into account 2.0.x, as long as the changes be commited on 2.0.x too. In few words, put this on trunk does not mean it will not run against 2.0 . A light way to deal with this kind of problem is take a look at myfaces tests project. It has two modules: 1.2 and 2.0, and 2.0 just take what it needs from 1.2 module and that's it. This reduce the burden to the minimum. regards, Leonardo Uribe -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3217) Integration tests for MyFaces core
[ https://issues.apache.org/jira/browse/MYFACES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072235#comment-13072235 ] Jakob Korherr commented on MYFACES-3217: Big objections here: -1 (sorry for the late answer!) The integration tests should not only be available for our latest trunk. JSF 2.0 still is used a lot and there are still a lot of bugs that come up. Please leave the module as is, I will add (NOT move) it to trunk soon. Integration tests for MyFaces core -- Key: MYFACES-3217 URL: https://issues.apache.org/jira/browse/MYFACES-3217 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.7, 2.1.1 Reporter: Jakob Korherr Assignee: Jakob Korherr Some time ago we already talked about the need for integration tests for MyFaces core in order to ensure the quality of MyFaces code, but we never created something for this. Now after successfully releasing MyFaces CODI v1.0.0 with a working integration-test concept, it is time to apply this concept also on MyFaces core. The concept is simple: use an integration-test module that will be added to the MyFaces core build via profile (-Pintegration-tests) and thus will not be part of a release. This module consists of a support module containing general integration-test support classes (e.g. an abstract MyFacesIntegrationTest base class for all JUnit integration-tests) and various war-modules that contain the actual integration-tests. The war modules use the cargo maven plugin to start and stop a specific container (e.g. jetty or tomcat) and HtmlUnit to run tests against the running server. The HtmlUnit tests are executed with the maven failsafe plugin to ensure container shutdown in error cases. I already created three war-modules with the following configuration: - servlet 2.5 and el 1.0 (jetty 7) - servlet 2.5 and el 2.2 (jetty 6 and glassfish el) - servlet 3.0 and el 2.2 (tomcat 7) These modules also already contain a very basic integration test, just as reference. The plan is to put basic tests that do not need any special configuration into these modules and to create new special war-modules for tests that need a specific configuration (e.g. MyFaces core on tomcat 6 with bean validation and client state saving enabled and ). In addition, I plan to create an archetype for these integration-test war-modules. The long-term plan would be to have an integration-test for every jira issue on MyFaces core, thus implementing test-driven-development. With the complete infrastructure in place, it should not be very hard to create a test case for a jira issue (maybe even already by the user that reports the issue) and thus being able to fix issues a lot quicker and to ensure that new code or changes do not break anything. I will create a wiki page describing this stuff in more detail, also giving examples on how to create modules and tests and on how to debug tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Use maven-shade-plugin to prevent duplicate code - revisited
in myfaces folder, you
can
setup a project that use api + all separate modules. In this way, if
there is an error on shared, you can compile just that module and
your
web application and that's it!. Sounds almost obvious, isn't it?.
Do this means change all package names on impl from shared-impl to
shared. Each module will have its own myfaces-metadata.xml, so
builder
plugin will work correctly.
Suggestions are welcome.
regards,
Leonardo Uribe
2011/7/11 Jakob Korherr jakob.korh...@gmail.com:
Hi,
I agree with Gerhard.
Unfortunately I did not try a whole release + site build with the
new
configuration since you always do that, Leo. So please check on
that
as soon as possible for you.
Regards,
Jakob
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi leo,
actually we should talk about the priority.
imo it has a very high priority!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/11 Leonardo Uribe lu4...@gmail.com
Hi Gerhard
Does somebody reviewed if the site documentation is generated
correctly? Isn't any problem with @JSFWebConfigParam? has anybody
debugged something with the proposed code?. That's the unresolved
questions I want to solve before apply it (I already mention that
without response, right?), but if somebody can answer those
questions
could speed it up.
I'm not asking for a loot of time. But note there are other
issues
right now ( improve error logging and exception handling,
MYFACES-3216, fix #{component} refs and isRendered(), improve
site
documentation ), that takes priority over this one.
regards,
Leonardo Uribe
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi leo,
right now i don't see a reason why it should take a lot of
time. in
the
end
you just have to look at the resulting artifacts.
the javadoc plugin is no blocker (if there is no official
release,
we
can do
an external release. as soon as there is an official release of
it,
we
can
switch back to it).
please provide a bit more information about the other issues.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/11 Leonardo Uribe lu4...@gmail.com
Hi
Please don't commit the changes until I do a final review.
That
will
take some time, so please be patient, there are other issues
on
core
right now that we need to solve too. Anyway we can't commit
the
code
without a release of javadoc plugin.
regards,
Leonardo Uribe
2011/7/11 Jakob Korherr jakob.korh...@gmail.com:
Hi,
right - there are no entries in the manifest. they will be
generated
for the separated osgi bundle/s during the build (based on
the
build
config).
Jep! That was the idea in the first place (look at the
branch
and
you'll see no bundle plugin in myfaces-api or myfaces-impl,
but
in
myfaces-bundle).
@Leo: From my point of view, the branch is complete. In
addition,
Mark
committed my patch for MJAVADOC-320, thus the javadoc
generation
does
already work too (if you use the latest 2.8.1-SNAPSHOT of
the
javadoc-plugin).
Here is a short summary of the proposed changes:
- remove felix bundle plugin executions from myfaces-api and
myfaces-impl (we have myfaces-bundle for OSGi).
- use maven-shade-plugin with package relocation (shared to
shared_impl) in myfaces-impl instead of
a) ant-task to rename source from shared to shared_impl
(myfaces-shared-impl project)
b) dependency plugin to unpack shared-impl-sources.jar in
myfaces-impl and build-helper-plugin to add these sources as
a
new
source folder
- use maven-javadoc-plugin with
includeSourceDependencies=true
for
shared (and impl-ee6) in order to include the javadocs of
shared
in
the myfaces-impl javadocs
These changes have the following implications:
- all imports of myfaces-shared code in myfaces-impl will go
to
org.apache.myfaces.shared.* instead of
org.apache.myfaces.shared_impl.*, because relocation is done
on
class-file-basis instead of source-file-basis.
- myfaces-shared-core will be a direct dependency of
myfaces-impl at
development time, thus enabling hot-deployments,... when
changing
stuff in shared at development time.
- myfaces-shared-impl project will be obsolete (b/c
[jira] [Commented] (MYFACES-3250) [perf] review StartupServletContextListener if HttpSessionAttributeListener is required
[ https://issues.apache.org/jira/browse/MYFACES-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072352#comment-13072352 ] Jakob Korherr commented on MYFACES-3250: this listener is needed to properly call @PreDestroy annotated methods of @SessionScoped managed beans! [perf] review StartupServletContextListener if HttpSessionAttributeListener is required --- Key: MYFACES-3250 URL: https://issues.apache.org/jira/browse/MYFACES-3250 Project: MyFaces Core Issue Type: Improvement Environment: myfaces trunk, tomcat 6.0.26 Reporter: Martin Kočí Priority: Minor When running stress test this is one of the most BLOCKED thread (blocked on some ArrayList monitor in tomcat internals): org.apache.catalina.core.ContainerBase.fireContainerEvent(String, Object) org.apache.catalina.session.StandardSession.fireContainerEvent(Context, String, Object) org.apache.catalina.session.StandardSession.setAttribute(String, Object, boolean) org.apache.catalina.session.StandardSession.setAttribute(String, Object) org.apache.catalina.session.StandardSessionFacade.setAttribute(String, Object) org.apache.myfaces.context.servlet.SessionMap.setAttribute(String, Object) org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String, Object) org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(Object, Object) This happens when someone puts a attribute into httpSession: org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(Object, Object) org.apache.myfaces.renderkit.ServerSideStateCacheImpl.nextViewSequence(FacesContext) org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.getResponseEncoding(FacesContext, String) org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(FacesContext, then Servlet container delivers event HttpSessionBindingEvent. in myfaces HttpSessionAttributeListener in implemented by oam.StartupServletContextListener and handles some stuff for managed beans. Review if this is needed - ideally remove it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3250) [perf] review StartupServletContextListener if HttpSessionAttributeListener is required
[ https://issues.apache.org/jira/browse/MYFACES-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13072374#comment-13072374 ] Jakob Korherr commented on MYFACES-3250: OK, nice. I would really like to see a prototype for the DISABLE_MANAGED_BEANS options with regard to the Deprecate managed bean mechanism-discussion for JSF 2.2. [perf] review StartupServletContextListener if HttpSessionAttributeListener is required --- Key: MYFACES-3250 URL: https://issues.apache.org/jira/browse/MYFACES-3250 Project: MyFaces Core Issue Type: Improvement Environment: myfaces trunk, tomcat 6.0.26 Reporter: Martin Kočí Priority: Minor When running stress test this is one of the most BLOCKED thread (blocked on some ArrayList monitor in tomcat internals): org.apache.catalina.core.ContainerBase.fireContainerEvent(String, Object) org.apache.catalina.session.StandardSession.fireContainerEvent(Context, String, Object) org.apache.catalina.session.StandardSession.setAttribute(String, Object, boolean) org.apache.catalina.session.StandardSession.setAttribute(String, Object) org.apache.catalina.session.StandardSessionFacade.setAttribute(String, Object) org.apache.myfaces.context.servlet.SessionMap.setAttribute(String, Object) org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String, Object) org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(Object, Object) This happens when someone puts a attribute into httpSession: org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(Object, Object) org.apache.myfaces.renderkit.ServerSideStateCacheImpl.nextViewSequence(FacesContext) org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.getResponseEncoding(FacesContext, String) org.apache.myfaces.renderkit.ServerSideStateCacheImpl.saveSerializedViewInServletSession(FacesContext, then Servlet container delivers event HttpSessionBindingEvent. in myfaces HttpSessionAttributeListener in implemented by oam.StartupServletContextListener and handles some stuff for managed beans. Review if this is needed - ideally remove it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: javascript docs
as the singleton objects. Again here is the link http://people.apache.org/~werpu/jsdoc/symbols/jsf.html Which means, I will rework the scripts first to allow jsdoc to compile them properly and then once done, I will integrate jsdoc properly into our build system. Werner Am 25.07.11 16:36, schrieb Werner Punz: Actually I am working on the impl classes so far it looks like I can pull it off the _Runtime.js can definitely be documented via jsdoc. The other classes which are more OO probably also can be mapped into our jsdocs. Am 25.07.11 15:35, schrieb Jakob Korherr: Very nice. Great job, Werner! Regards, Jakob 2011/7/25 Werner Punzwerner.p...@gmail.com: Hi everyone, I have started this week to work on the javascript documentation issues, so far I can cover our API classes pretty well with jsdoc. Only one minor code modification was needed to get it up and running. Here is a first rough result by using jsdoc on the API section: http://people.apache.org/~werpu/jsdoc/symbols/jsf.html Since my first goal simply was to get the api docs out I will merge this into our maven build and do the code adjustements as needed. To get jsdocs for the impl is a nice to have but not vital, since the impl classes should not be used anyway by the users. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Commented] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071009#comment-13071009 ] Jakob Korherr commented on MYFACES-3235: I agree with Bernd, the discussion can stay in the JIRA (a mail to the dev-list is sent anyway). Furthermore it is easier to see the whole conversation! Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071010#comment-13071010 ] Jakob Korherr commented on MYFACES-3235: I agree with Bernd, the discussion can stay in the JIRA (a mail to the dev-list is sent anyway). Furthermore it is easier to see the whole conversation! Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3235) Create infrastructure for improved logging
[ https://issues.apache.org/jira/browse/MYFACES-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070369#comment-13070369 ] Jakob Korherr commented on MYFACES-3235: I totally agree with Mark. Please no i18n-ized error messages in the console! Create infrastructure for improved logging --- Key: MYFACES-3235 URL: https://issues.apache.org/jira/browse/MYFACES-3235 Project: MyFaces Core Issue Type: Sub-task Components: General Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3235.patch Create classes like MyfacesLogger, MyfacesLogRecord etc. like Trinidad has. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ORCHESTRA-58) ConversationManager should use equals to check for dummy id
ConversationManager should use equals to check for dummy id --- Key: ORCHESTRA-58 URL: https://issues.apache.org/jira/browse/ORCHESTRA-58 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.4 Reporter: Jakob Korherr Assignee: Jakob Korherr (from Mathias Scharl) The ConversationManager uses a DUMMY variable set to new Integer(-1). Later in the code this DUMMY is used to check for an invalid conversation id. Unfortunately this check is done via == instead of equals, which works most of the time, but after re-starting an application in tomcat (session is passivated), the DUMMY object is not the same anymore and the check does not work as expected. The solution is to use equals instead of ==. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3217) Integration tests for MyFaces core
[ https://issues.apache.org/jira/browse/MYFACES-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064615#comment-13064615 ] Jakob Korherr commented on MYFACES-3217: FYI: I just changed the servlet25-el10 environment from jetty7 to tomcat6, b/c tomcat6 is potentially more often used than jetty7. Integration tests for MyFaces core -- Key: MYFACES-3217 URL: https://issues.apache.org/jira/browse/MYFACES-3217 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.7, 2.1.1 Reporter: Jakob Korherr Assignee: Jakob Korherr Some time ago we already talked about the need for integration tests for MyFaces core in order to ensure the quality of MyFaces code, but we never created something for this. Now after successfully releasing MyFaces CODI v1.0.0 with a working integration-test concept, it is time to apply this concept also on MyFaces core. The concept is simple: use an integration-test module that will be added to the MyFaces core build via profile (-Pintegration-tests) and thus will not be part of a release. This module consists of a support module containing general integration-test support classes (e.g. an abstract MyFacesIntegrationTest base class for all JUnit integration-tests) and various war-modules that contain the actual integration-tests. The war modules use the cargo maven plugin to start and stop a specific container (e.g. jetty or tomcat) and HtmlUnit to run tests against the running server. The HtmlUnit tests are executed with the maven failsafe plugin to ensure container shutdown in error cases. I already created three war-modules with the following configuration: - servlet 2.5 and el 1.0 (jetty 7) - servlet 2.5 and el 2.2 (jetty 6 and glassfish el) - servlet 3.0 and el 2.2 (tomcat 7) These modules also already contain a very basic integration test, just as reference. The plan is to put basic tests that do not need any special configuration into these modules and to create new special war-modules for tests that need a specific configuration (e.g. MyFaces core on tomcat 6 with bean validation and client state saving enabled and ). In addition, I plan to create an archetype for these integration-test war-modules. The long-term plan would be to have an integration-test for every jira issue on MyFaces core, thus implementing test-driven-development. With the complete infrastructure in place, it should not be very hard to create a test case for a jira issue (maybe even already by the user that reports the issue) and thus being able to fix issues a lot quicker and to ensure that new code or changes do not break anything. I will create a wiki page describing this stuff in more detail, also giving examples on how to create modules and tests and on how to debug tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Integration tests for MyFaces core
Hi, One idea that came to my mind is how to run the same set of tests against multiple configurations. For example, if we have some ajax tests, it could be good to run it with htmlunit in firefox and IE mode, or we need to run some test with PSS or normal state saving, and so on. Other idea is take some tests already done in test-webapp project and automatize it (flash scope tests and some other ajax tests). It looks very promising. Yes, I was thinking of the need for running one test in different environments too. However, due to the different configurations needed (e.g. web.xml config parameters), it is not that easy to accomplish something like that. Fortunately - as Gerhard mentioned - Jan Zarnikov is currently working on something like that for his GSoC project Manila. After GSoC is over, we will be able to use this framework to accomplish this task (it already looks very promising!). I also agree that we should port some of the manual tests from test-webapp to the new integration-test modules. I think this would be a good task for our summer student. I will check that with him! The idea of the integration-test war modules is to keep them as simple as possible. If a very specific config is needed for one tests, a new module should be created simply for this concrete test. FYI 1: I just changed the servlet25-el10 environment from jetty7 to tomcat6, b/c tomcat6 is potentially more often used than jetty7. FYI 2: I created a job called myfaces-current-2.0-integration-tests on jenkins to execute the integration tests for core (we use a different job then the original myfaces-current-2.0 job, because we don't want a failing integration-test to stop the deployment of our snapshots, we did that on CODI too). After some minor start problems, it works now! FYI 3: I will start creating the archetype for core integration tests now! Regards, Jakob 2011/7/12 Rudy De Busscher rdebussc...@gmail.com: If have done lately some tests with Selenium Webdriver running against different browsers (see [1]) It is quit easy and give you immediate indication about the browser compatibility. Nice to have that kind of 'assurance' into MyFaces. Regards Rudy [1] = http://jsfcorner.blogspot.com/2011/05/browser-compatibility-with-webdriver.html On 12 July 2011 19:32, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi, +1 @leo: jan is working on a similar topic - see [1] regards, gerhard [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg53910.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/12 Leonardo Uribe lu4...@gmail.com Hi Looks great!. One idea that came to my mind is how to run the same set of tests against multiple configurations. For example, if we have some ajax tests, it could be good to run it with htmlunit in firefox and IE mode, or we need to run some test with PSS or normal state saving, and so on. Other idea is take some tests already done in test-webapp project and automatize it (flash scope tests and some other ajax tests). It looks very promising. Leonardo Uribe 2011/7/12 Jakob Korherr jakob.korh...@gmail.com: Hi guys, I just opened a JIRA issue (MYFACES-3217) and committed the basic infrastructure for the MyFaces core integration tests. I added a detailed description about the integration-tests to the JIRA issue, so please have a look at that. In addition, you can check out the modules in the svn at [1]. If you want to build MyFaces core 2.0.x and run the integration tests with the build, just use mvn clean install -Pintegration-tests. If you want to start a container and do some tests manually, just run mvn clean package cargo:run in one of the war-modules. If you have some time, please give it a try and tell me what you think about it! In addition, we at IRIAN just got a summer student aboard who is willing to write a basic set of integration tests for us. Thus we should soon have a lot of tests in those modules! Any comments, ideas or other input is appreciated! Regards, Jakob [1] https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/integration-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Rudy De Busscher http://www.c4j.be -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Integration tests for MyFaces core
Hi, I just created a wiki page in the cwiki for the integration-tests: https://cwiki.apache.org/confluence/display/MYFACES/MyFaces+core+integration+tests Regards, Jakob 2011/7/13 Jakob Korherr jakob.korh...@gmail.com: Hi, One idea that came to my mind is how to run the same set of tests against multiple configurations. For example, if we have some ajax tests, it could be good to run it with htmlunit in firefox and IE mode, or we need to run some test with PSS or normal state saving, and so on. Other idea is take some tests already done in test-webapp project and automatize it (flash scope tests and some other ajax tests). It looks very promising. Yes, I was thinking of the need for running one test in different environments too. However, due to the different configurations needed (e.g. web.xml config parameters), it is not that easy to accomplish something like that. Fortunately - as Gerhard mentioned - Jan Zarnikov is currently working on something like that for his GSoC project Manila. After GSoC is over, we will be able to use this framework to accomplish this task (it already looks very promising!). I also agree that we should port some of the manual tests from test-webapp to the new integration-test modules. I think this would be a good task for our summer student. I will check that with him! The idea of the integration-test war modules is to keep them as simple as possible. If a very specific config is needed for one tests, a new module should be created simply for this concrete test. FYI 1: I just changed the servlet25-el10 environment from jetty7 to tomcat6, b/c tomcat6 is potentially more often used than jetty7. FYI 2: I created a job called myfaces-current-2.0-integration-tests on jenkins to execute the integration tests for core (we use a different job then the original myfaces-current-2.0 job, because we don't want a failing integration-test to stop the deployment of our snapshots, we did that on CODI too). After some minor start problems, it works now! FYI 3: I will start creating the archetype for core integration tests now! Regards, Jakob 2011/7/12 Rudy De Busscher rdebussc...@gmail.com: If have done lately some tests with Selenium Webdriver running against different browsers (see [1]) It is quit easy and give you immediate indication about the browser compatibility. Nice to have that kind of 'assurance' into MyFaces. Regards Rudy [1] = http://jsfcorner.blogspot.com/2011/05/browser-compatibility-with-webdriver.html On 12 July 2011 19:32, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi, +1 @leo: jan is working on a similar topic - see [1] regards, gerhard [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg53910.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/12 Leonardo Uribe lu4...@gmail.com Hi Looks great!. One idea that came to my mind is how to run the same set of tests against multiple configurations. For example, if we have some ajax tests, it could be good to run it with htmlunit in firefox and IE mode, or we need to run some test with PSS or normal state saving, and so on. Other idea is take some tests already done in test-webapp project and automatize it (flash scope tests and some other ajax tests). It looks very promising. Leonardo Uribe 2011/7/12 Jakob Korherr jakob.korh...@gmail.com: Hi guys, I just opened a JIRA issue (MYFACES-3217) and committed the basic infrastructure for the MyFaces core integration tests. I added a detailed description about the integration-tests to the JIRA issue, so please have a look at that. In addition, you can check out the modules in the svn at [1]. If you want to build MyFaces core 2.0.x and run the integration tests with the build, just use mvn clean install -Pintegration-tests. If you want to start a container and do some tests manually, just run mvn clean package cargo:run in one of the war-modules. If you have some time, please give it a try and tell me what you think about it! In addition, we at IRIAN just got a summer student aboard who is willing to write a basic set of integration tests for us. Thus we should soon have a lot of tests in those modules! Any comments, ideas or other input is appreciated! Regards, Jakob [1] https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/integration-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Rudy De Busscher http://www.c4j.be -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] [Created] (MYFACES-3217) Integration tests for MyFaces core
Integration tests for MyFaces core -- Key: MYFACES-3217 URL: https://issues.apache.org/jira/browse/MYFACES-3217 Project: MyFaces Core Issue Type: Task Affects Versions: 2.1.1, 2.0.7 Reporter: Jakob Korherr Assignee: Jakob Korherr Some time ago we already talked about the need for integration tests for MyFaces core in order to ensure the quality of MyFaces code, but we never created something for this. Now after successfully releasing MyFaces CODI v1.0.0 with a working integration-test concept, it is time to apply this concept also on MyFaces core. The concept is simple: use an integration-test module that will be added to the MyFaces core build via profile (-Pintegration-tests) and thus will not be part of a release. This module consists of a support module containing general integration-test support classes (e.g. an abstract MyFacesIntegrationTest base class for all JUnit integration-tests) and various war-modules that contain the actual integration-tests. The war modules use the cargo maven plugin to start and stop a specific container (e.g. jetty or tomcat) and HtmlUnit to run tests against the running server. The HtmlUnit tests are executed with the maven failsafe plugin to ensure container shutdown in error cases. I already created three war-modules with the following configuration: - servlet 2.5 and el 1.0 (jetty 7) - servlet 2.5 and el 2.2 (jetty 6 and glassfish el) - servlet 3.0 and el 2.2 (tomcat 7) These modules also already contain a very basic integration test, just as reference. The plan is to put basic tests that do not need any special configuration into these modules and to create new special war-modules for tests that need a specific configuration (e.g. MyFaces core on tomcat 6 with bean validation and client state saving enabled and ). In addition, I plan to create an archetype for these integration-test war-modules. The long-term plan would be to have an integration-test for every jira issue on MyFaces core, thus implementing test-driven-development. With the complete infrastructure in place, it should not be very hard to create a test case for a jira issue (maybe even already by the user that reports the issue) and thus being able to fix issues a lot quicker and to ensure that new code or changes do not break anything. I will create a wiki page describing this stuff in more detail, also giving examples on how to create modules and tests and on how to debug tests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Integration tests for MyFaces core
Hi guys, I just opened a JIRA issue (MYFACES-3217) and committed the basic infrastructure for the MyFaces core integration tests. I added a detailed description about the integration-tests to the JIRA issue, so please have a look at that. In addition, you can check out the modules in the svn at [1]. If you want to build MyFaces core 2.0.x and run the integration tests with the build, just use mvn clean install -Pintegration-tests. If you want to start a container and do some tests manually, just run mvn clean package cargo:run in one of the war-modules. If you have some time, please give it a try and tell me what you think about it! In addition, we at IRIAN just got a summer student aboard who is willing to write a basic set of integration tests for us. Thus we should soon have a lot of tests in those modules! Any comments, ideas or other input is appreciated! Regards, Jakob [1] https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/integration-tests/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Use maven-shade-plugin to prevent duplicate code - revisited
will prevent @JSFWebConfigParam annotations to be scanned for myfaces builder plugin and consequently break this generated site page: http://myfaces.apache.org/core20/myfaces-impl/webconfig.html http://myfaces.apache.org/core21/myfaces-impl/webconfig.html I don't see very clear the benefits of the change. I suppose it enhance debugging in some way, but is that true? can I do a change on shared, and do not have to recompile to see the change? If I set a break point on shared-core, the debugger will stop there? I would like to see a strong (and maybe heavier and tedious but necessary) argumentation before do the change. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com: hi mark, that's a bit off-topic ;) we already (have to) provide osgi bundles. we just continue to do the same with the shade-plugin. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Mark Struberg strub...@yahoo.de Hi folks! There are 2 problems with JSF under OSGi a) OSGi is in reality a _big_ mess and not really worth the troubles ;) It _should_ make it possible to elegantly switch implementations, but in practice you need to import/export all packages explicitly, even those which are only used indirectly. b) the design of the JSF-api could be more clear with separation (hey, it's 10 years old!). It is not possible to use a MyFaces-impl with a mojarra-api and vice versa, because methods like FacesContext#getCurrentInstance() (and similar) access impl classes from the API package. This makes it pretty hard to work OSGi. LieGrue, strub --- On Fri, 7/8/11, Jakob Korherr jakob.korh...@gmail.com wrote: From: Jakob Korherr jakob.korh...@gmail.com Subject: Re: Use maven-shade-plugin to prevent duplicate code - revisited To: MyFaces Development dev@myfaces.apache.org Date: Friday, July 8, 2011, 1:09 PM Hi Leo, Yes, I remember that you did some work related to this stuff. Some comments about your problems: 1) If you use myfaces-impl, the packages really are *.shared_impl.* (shade does the relocation on the classes). But a part of this statement is still true - we need to check config files with references to shared and shared_impl. 2) That's not true. We solved this problem in CODI, as described. Please take a look at the code ;) 3) We don't need to execute felix bundle plugin directly in myfaces-impl, b/c it won't work in an OSGi environment anyway (see e.g. FactoryFinder problems). We have myfaces-bundle for this matter! Regards, Jakob 2011/7/7 Leonardo Uribe lu4...@gmail.com: Hi I haven't look the code provided in deep, but long time ago I tried it. In that time I saw the following problems: 1. There are some classes on shared that are used outside it. For example, see org.apache.myfaces.shared.webapp.webxml.DelegatedFacesServlet. We need to detect all similar cases and move those classes to myfaces-impl, but renaming shared with shared-impl, or just create classes that extends from the ones in shared, to preserve backward behavior. In theory, the affected packages are: org.apache.myfaces.shared_impl.webapp.webxml org.apache.myfaces.shared_impl.taglib org.apache.myfaces.shared_impl.taglib.core 2. Generated artifacts (-sources.jar, -javadoc.jar) has problems. It is clear javadoc and source jars will not have shared-impl. 3. shade plugin and felix maven bundle plugin does not play well. By default bundle plugin is executed before shade plugin, but what you want is the opposite, so the information on MANIFEST.MF could be generated taking into account all classes. Note if we solve 1, this should not be a problem, because classes inside shared are myfaces internals (remember why spi interfaces are on impl package and not in shared). I'll keep an eye on the resulting work. regards, Leonardo Uribe 2011/7/7 Gerhard Petracek gerhard.petra...@gmail.com: hi jakob, great - thx! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/7 Jakob Korherr
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
relocation for some classes (from org.apache.myfaces.config.element to org.apache.myfaces.spi.data). Those changes will break extensions scripting code. Such changes should be done between major versions (2.2.0). Please do not change the package names. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/8 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com Hi guys, We currently use the shaded-impl module in core 2.1.x to solve a cyclic dependency problem. However, this introduces redundancy and complexity and may lead to some strange issues. This can be solved by the introduction of a myfaces-spi module (which is then packed together with myfaces-impl, just like myfaces-impl-ee6 is). Please see MYFACES-3211 [1] for a detailed description of the solution and a patch for it. If there are no objections, I will commit this patch soon! Regards, Jakob [1] https://issues.apache.org/jira/browse/MYFACES-3211 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From a user point of view: maybe yes. But from a developer point of view myfaces-shaded-impl is an epic fail. I know it was an easy an fast solution at the time we got 2.1.0 out, but for the long term this has to be changed. Please think about it, you use 2.0.5 (or any other _previous_ version) in myfaces-impl-ee6 as if it was 2.1.x-SNAPSHOT. Thus you use internals of previous versions which might not even be there anymore in the current 2.1.x-SNAPSHOT. And the worst part of it: you don't even see it at build time, b/c it's a separate module and myfaces-impl-ee6 is shaded into myfaces-impl (and shade does not warn about this kind of stuff, of course). I know the hack done to compile 2.1 is not very clean, but it works. The idea is replace 2.0.5 ref with 2.1.0 in future versions. Note myfaces-shaded-impl is a module that is just for allow compile myfaces-impl-ee6, and nobody else. It is not an epic fail, because it does not cause any changes on the code that cause problems. Considering this, it was ok to create shaded-impl in order to get the 2.1.0 release out, but for future releases (maybe also towards 2.2.0), this must be done in another way. In fact, the idea is do something in 2.2.x, but that will take some time, so maybe we can keep in mind those changes until get there. I have to say that I won't support a 2.1.2 release including the shaded-impl module. I hope my arguments could be enough to convince you about the opposite. regards , Leonardo Uribe Regards, Jakob 2011/7/10 Leonardo Uribe lu4...@gmail.com: Hi Gerhard Ok, in theory the parts that we should not change, or otherwise that will trigger a change on JEE containers are: 1. All classes in org.apache.myfaces.spi. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. regards
Re: GSOC 2011: MyFaces webapp tests
Hi Jan, Yes, thanks a lot for the update on your project! Regards, Jakob 2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com: hi jan, sounds great - thx for the update! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jan Zarnikov jan.zarni...@gmail.com Hi, in the last few weeks I've been working on the GSOC project for Apache Myfaces (see http://wiki.apache.org/myfaces/GSoC2011_AutomatedTests) If you are curious you can check out the current source from http://subversion.assembla.com/svn/manila/ What's working: * starting tests in different JVM (fixes the classpath problem) * resolving of maven artifacts (including transitives) * starting same test in different configurations Still on the TODO list: * Implementation of the assertions (I'll be reusing parts of the code from GSOC2010) * Examples * Documentation Any feedback will be appreciated. Regards, Jan On Wed, Mar 30, 2011 at 11:06 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Jan, Great to hear that! Welcome to MyFaces :) Regards, Jakob 2011/3/30 Gerhard Petracek gerhard.petra...@gmail.com: hi jan, that would be great! welcome @myfaces! please start writing a wiki page like cosmin did last year [1]. regards, gerhard [1] http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/3/30 Jan Zarnikov jan.zarni...@gmail.com Hello, I would like to participate in Google Summer of Code 2011. I'm currently finishing my master studies in computer science at the University of Technology in Vienna. I looked at the topics for this year and I'm interested in MyFaces webapp tests (https://issues.apache.org/jira/browse/MYFACESTEST-47). I checked out the result of last year's GSOC by Cosmin and I like the concept behind it. Regards, Jan Zarnikov -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Use maven-shade-plugin to prevent duplicate code - revisited
Hi,
I agree with Gerhard.
Unfortunately I did not try a whole release + site build with the new
configuration since you always do that, Leo. So please check on that
as soon as possible for you.
Regards,
Jakob
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi leo,
actually we should talk about the priority.
imo it has a very high priority!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/11 Leonardo Uribe lu4...@gmail.com
Hi Gerhard
Does somebody reviewed if the site documentation is generated
correctly? Isn't any problem with @JSFWebConfigParam? has anybody
debugged something with the proposed code?. That's the unresolved
questions I want to solve before apply it (I already mention that
without response, right?), but if somebody can answer those questions
could speed it up.
I'm not asking for a loot of time. But note there are other issues
right now ( improve error logging and exception handling,
MYFACES-3216, fix #{component} refs and isRendered(), improve site
documentation ), that takes priority over this one.
regards,
Leonardo Uribe
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi leo,
right now i don't see a reason why it should take a lot of time. in the
end
you just have to look at the resulting artifacts.
the javadoc plugin is no blocker (if there is no official release, we
can do
an external release. as soon as there is an official release of it, we
can
switch back to it).
please provide a bit more information about the other issues.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/11 Leonardo Uribe lu4...@gmail.com
Hi
Please don't commit the changes until I do a final review. That will
take some time, so please be patient, there are other issues on core
right now that we need to solve too. Anyway we can't commit the code
without a release of javadoc plugin.
regards,
Leonardo Uribe
2011/7/11 Jakob Korherr jakob.korh...@gmail.com:
Hi,
right - there are no entries in the manifest. they will be generated
for the separated osgi bundle/s during the build (based on the build
config).
Jep! That was the idea in the first place (look at the branch and
you'll see no bundle plugin in myfaces-api or myfaces-impl, but in
myfaces-bundle).
@Leo: From my point of view, the branch is complete. In addition,
Mark
committed my patch for MJAVADOC-320, thus the javadoc generation does
already work too (if you use the latest 2.8.1-SNAPSHOT of the
javadoc-plugin).
Here is a short summary of the proposed changes:
- remove felix bundle plugin executions from myfaces-api and
myfaces-impl (we have myfaces-bundle for OSGi).
- use maven-shade-plugin with package relocation (shared to
shared_impl) in myfaces-impl instead of
a) ant-task to rename source from shared to shared_impl
(myfaces-shared-impl project)
b) dependency plugin to unpack shared-impl-sources.jar in
myfaces-impl and build-helper-plugin to add these sources as a new
source folder
- use maven-javadoc-plugin with includeSourceDependencies=true for
shared (and impl-ee6) in order to include the javadocs of shared in
the myfaces-impl javadocs
These changes have the following implications:
- all imports of myfaces-shared code in myfaces-impl will go to
org.apache.myfaces.shared.* instead of
org.apache.myfaces.shared_impl.*, because relocation is done on
class-file-basis instead of source-file-basis.
- myfaces-shared-core will be a direct dependency of myfaces-impl at
development time, thus enabling hot-deployments,... when changing
stuff in shared at development time.
- myfaces-shared-impl project will be obsolete (b/c - as already
mentioned - myfaces-impl uses shared-core instead of shared-impl).
If there are no objections, I will merge in the changes from the
branch
soon!
Regards,
Jakob
2011/7/8 Leonardo Uribe lu4...@gmail.com:
Hi Gerhard
Ok, now that part has sense.
There are still some things to check before apply the change. Please
let me know when all code is on the branch and I'll do a final
in-deep
check.
regards,
Leonardo Uribe
2011/7/8 Gerhard Petracek gerhard.petra...@gmail.com:
hi leo,
right - there are no entries in the manifest. they will be
generated
for the
separated osgi bundle/s during the build (based on the build
config).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/8 Leonardo Uribe lu4...@gmail.com
Hi
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can add methods there, but relocate this package to org.apache.myfaces.spi.data is not necessary. I think the package name is correct. OK, fine. I thought the relocation to org.apache.myfaces.spi.* would fit better, since it is the myfaces-spi module and, again, since we're talking about 2.1.x, not 2.0.x here. But if you want to keep the package-name, I have no problem with that. org.apache.myfaces.config.element is fine too, however, you may not expect it to be in the myfaces-spi module. [...] Considering this, I think the costs involved on the changes proposed are too big compared with the benefits, which are very limited and almost inexistent from user point of view. From
Re: Proposal: Get rid of shaded-impl module in core 2.1.x
Hi Gerhard, OK, thx. Will do so! Regards, Jakob 2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com: hi jakob, i suggest the same approach like before. last time leo requested some changes and had to start the vote (with a short description) and this time it's your turn. if you feel that we need a vote about it, please feel free to start one. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/7/11 Jakob Korherr jakob.korh...@gmail.com Hi, Leo, I really get your point that we can't change this stuff. Changing SPI stuff (even just renaming packages) will break application server integation code, we all got it now.. That's why I suggested (a few mails ago, but unfortunately too vague) keeping the package names *.spi, *.spi.impl and *.config.element as is, but still moving *.spi and *.config.element to a new module called myfaces-spi. This alone will let us be able to remove shaded-impl, no code change is actually required, just moving some classes from myfaces-impl into myfaces-spi. In the end (-- the myfaces-impl jar), it will all be back in myfaces-impl again, because of shade. I will provide a new patch by tomorrow and then start a vote for it. There really is no technical reason for not committing such a solution at this point. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi I'll be clear and direct. What makes statements true or false are the reasons behind it. Until this moment, you are not question the reasons behind the reasoning proposed. To be short, my argumentation is we can't change for now: 1. Everything inside org.apache.myfaces.spi 2. LifecycleProvided 3. Everything inside org.apache.myfaces.config.element because JSF 2.1 is a maintenance release (not a mayor release) which already has it first version (but even without a version). Do that will create bugs on server integration code. The problem is there is no way to detect such changes or create a proper patch from the server side point of view without use some ugly reflection code and that really s...cks!. Let it to JSF 2.2 (which is another JSR) sounds better because in that time I think we can get rid of implee6 too in one move!. In that version, just change the poms, and move all code to impl and that's it. In conclusion, here we have a technical restriction that doesn't allow us to move further, so we can't really make a vote because there is no decision to make, we just can't change the code!. The idea of an API in impl module is precisely make the promise that we will be nice and do not change that stuff until the next major version. Unfortunately there is nothing we can do in 2.1.x branch. regards, Leonardo Uribe 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, No, sorry Leo, they are not enough. Frankly, I don't understand why you are blocking this solution. It is easy, it does not break anything (if we do not change the package names), it is a lot more clean and we can get rid of the shaded-impl module. If we don't do this now, we will maybe have to use this ugly module for a long time.. And yes: in my opinion it is an epic fail. If you think otherwise, that's ok, but just because you say so and I don't does not make your statement true. I think we have to start a vote for this one just like we did with the resource-handler stuff. Regards, Jakob 2011/7/11 Leonardo Uribe lu4...@gmail.com: Hi 2011/7/11 Jakob Korherr jakob.korh...@gmail.com: Hi, 1. All classes in org.apache.myfaces.spi. I did not change anything here, just internal imports (from *.spi.impl to *.spi.util)! It is questionable to create .spi.util. After all, it is not supposed that package be consumed by container integration code, so it should be on spi.impl. 2. All classes that has to be with LifecycleProvider (@PostConstruct annotation). Such classes should be on spi package, but note spi work started after 2.0 release, so this should wait to a major version. Geronimo (for which we did the SPI stuff) includes MyFaces 2.0.x. Here we are talking about 2.1.x. Furthermore, one call to organize imports does the trick, so I do not see a problem here. Look the page of JSR-314 spec http://www.jcp.org/en/jsr/summary?id=314 You will notice 2.1.x is not a new JSR like the future JSR-344 (JSF 2.2), and instead is tagged as Maintenance Release 2. So, to be consistent, it should be possible to change between 2.0 and 2.1 on the same server. That's the most important reason to be so conservative or strict with 2.1. 3. All classes on org.apache.myfaces.config.element. These classes are an interface to manipulate faces-config.xml files with java code, and spi interfaces provide the hooks to get them, so in theory we can
