[ANNOUNCE] MyFaces Core v2.3.0-beta Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.3.0-beta. MyFaces Core is a JavaServer(tm) Faces 2.3 implementation as specified by JSR-372. MyFaces Core 2.3.0-beta is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.3.0-beta Sub-task [MYFACES-4092] - Implement CDI extension for @FacesDataModel [MYFACES-4093] - Implement CDI extension for @FacesConverter [MYFACES-4094] - Implement CDI extension for @FacesValidator [MYFACES-4095] - Implement CDI extension for @FacesBehavior [MYFACES-4096] - Implement CDI extension for @ManagedProperty [MYFACES-4097] - Implement CDI changes for @FacesConfig Bug [MYFACES-3644] - cleanup ViewState handling [MYFACES-4104] - Update plugins to compile java 8 code in JSF 2.3 branch [MYFACES-4105] - Implement extensionless mapping of views [MYFACES-4107] - StringIndexOutOfBoundsException in getResourceVersion [MYFACES-4117] - No default name for @FacesComponent with createTag=true and no tagName [MYFACES-4119] - Disposal method from PushContextFactoryBean is missing @Push annotation Improvement [MYFACES-4099] - Allow resolve #{cc} inside templates called from a composite component [MYFACES-4102] - Check improvements in FlowHandler for JSF 2.3 New Feature [MYFACES-4069] - Implement f:websocket and related api [MYFACES-4070] - Implement h:commandScript and related api [MYFACES-4071] - Implement dynamic resource loading in ajax requests [MYFACES-4075] - SearchExpression API [MYFACES-4078] - Expose StateCacheFactory/StateCache as a SPI service [MYFACES-4079] - Implement CDI changes for JSF 2.3 [MYFACES-4083] - Add copy constructor to wrappers [MYFACES-4084] - Implement f:importConstants [MYFACES-4085] - Constants for "jsf.js", "javax.faces" and postback parameters [MYFACES-4086] - Deprecate native managed beans annotations [MYFACES-4087] - Add PostRenderViewEvent [MYFACES-4088] - Add constructor with facesContext to event classes [MYFACES-4089] - Add Iterable support in UIData and UIRepeat [MYFACES-4090] - Add Map support in UIData and UIRepeat [MYFACES-4091] - Add custom type support in UIData and UIRepeat [MYFACES-4098] - Implement ResourceHandler.getViewResources(...) [MYFACES-4101] - Implement f:importConstants [MYFACES-4103] - Implement ViewHandler.getViews(...) [MYFACES-4106] - Implement ResourceHandler.markResourceRendered(...) and ResourceHandler.isResourceRendered(...) [MYFACES-4108] - Implement FaceletCache.setCacheFactories(...) [MYFACES-4109] - Implement f:validateWholeBean [MYFACES-4110] - Implement javax.faces.model.IterableDataModel [MYFACES-4111] - Implement h:column styleClass property [MYFACES-4112] - Implement h:dataTable rowClass [MYFACES-4113] - Implement h:panelGrid rowClass [MYFACES-4115] - Implement h:selectOneRadio "group" (distributed radio button) [MYFACES-4116] - Implement JDK 8 time support in f:convertDateTime [MYFACES-4118] - Implement new changes of javax.faces.ViewState update on ajax for multiple forms Task [MYFACES-4121] - Fix javadoc for 2.3 branch and update maven-javadoc-plugin regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.12 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.12. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.12 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.2.12 Bug [MYFACES-4064] - EL 3.0 Collection construction broken [MYFACES-4066] - FlowBuilderFactoryBean Concurrency Issue [MYFACES-4068] - Ajax-Listener (PrimeFaces) is not called for some selection-components [MYFACES-4072] - passthrough checked always set regards, Leonardo Uribe
Re: Reg vulnerability for Server State saving
Hi It is in the wiki page. See org.apache.myfaces.ALGORITHM.IV web config param for details. If you want to take a look at the class where the encryption happens, see org.apache.myfaces.shared.util.StateUtils in http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StateUtils.java regards, Leonardo Uribe 2017-01-29 23:39 GMT-05:00 karthik kn <keyan...@gmail.com>: > Any thoughts on the below ? > > On Fri, Jan 27, 2017 at 10:57 AM, karthik kn <keyan...@gmail.com> wrote: > > > Hi All, > > We were able to update the jsf version to the lates and randomly generate > > the enc key as mentioned in > > https://wiki.apache.org/myfaces/Secure_Your_Application > > > > However, the Initialization vector for CBC needs to be mentioned. Can we > > not generate it randomly ? > > > > Is this a bug in JSF ? > > > > If i could generate the Enc key, then the IV should have been generated > > randomly. > > > > Please let know > > > > On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko < > > andraschko.tho...@gmail.com> wrote: > > > >> Hi, > >> > >> i don't think there is any other way to configure it but you can still > >> check the sources: http://svn.apache.org/viewvc/m > >> yfaces/core/branches/1.1.x/ > >> > >> Regards, > >> Thomas > >> > >> 2016-12-23 11:21 GMT+01:00 karthik kn <keyan...@gmail.com>: > >> > >> > Hi All, > >> > Any thoughts on the below ? > >> > > >> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <keyan...@gmail.com> > >> wrote: > >> > > >> > > Hi, > >> > > If i use a new key in web.xml as SECRET, it could be still exposed > to > >> > the > >> > > Administrator on accessing the system. > >> > > > >> > > Wont this cause a vulnerability ? Is there any other mechanism of > >> storing > >> > > the secret ? > >> > > > >> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <bech...@agno3.eu> > >> > wrote: > >> > > > >> > >> Hi, > >> > >> > >> > >> > Thank you for clarification. Using the secret mentioned in the > >> below > >> > >> page > >> > >> > would suffice or there is some mechanism to generate the SECRET ? > >> > >> > > >> > >> > >> > >> You must not use the keys specified on this page but generate your > >> own > >> > >> secret ones. An attacker using the same key can then produce a > valid > >> > >> ViewState token containing an exploit. Also, as noted on the > security > >> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8, > 2.0.0 > >> > >> are vulnerable to padding oracle attacks (I haven't had a close > look > >> but > >> > >> I would be pretty sure that also applies to server side state > >> saving). > >> > >> That means that an attacker may be able to create such tokens > without > >> > >> the knowledge of the key - again allowing for the same exploits. > >> > >> > >> > >> So I guess there is no way to be really safe without upgrading. > >> > >> > >> > >> > >> > >> Moritz > >> > >> > >> > >> PS: you also might want to consider using something stronger than > >> DES. > >> > >> > >> > >> > >> > >> -- > >> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA > 728731 > >> > >> Persönlich haftend: > >> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB > >> 744820, > >> > >> Vertreten durch Joachim Keltsch > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > - > >> > > Thanks & Regards > >> > > > >> > > Karthik.K.N > >> > > > >> > > >> > > >> > > >> > -- > >> > - > >> > Thanks & Regards > >> > > >> > Karthik.K.N > >> > > >> > > > > > > > > -- > > - > > Thanks & Regards > > > > Karthik.K.N > > > > > > -- > - > Thanks & Regards > > Karthik.K.N >
Re: Reg vulnerability for Server State saving
Hi 1.1.5 is too old. Please update to 1.1.8 or upper versions. See https://wiki.apache.org/myfaces/Secure_Your_Application for details. regards, Leonardo Uribe 2016-12-19 5:44 GMT-05:00 karthik kn <keyan...@gmail.com>: > Hi, > I am using myfaces-1.1.5 and using the following state saving method > > javax.faces.STATE_SAVING_ > METHODserver > > However,i see that the object identifier is being sent to the server as > following > > id="javax.faces.ViewState" > value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAN0 > AAEzcHQAJi9qc3AvaGxyL2FjX3N1YnNjcmliZXIvY3J0U2luZ2xlQUMuanNw" > /> > > This is the serialized object identifier sent over the network > > We are using only https and not http. > > Does sending this serialized object identifier without encrypting open any > vulnerability which the attacker could use to his/her advantage ? > > -- > - > Thanks & Regards > > Karthik.K.N >
[ANNOUNCE] MyFaces Core v2.2.11 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.11. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.11 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.2.11 Bug [MYFACES-4036] - UIData state is not restorable when rowStatePreserved is set to true [MYFACES-4047] - @PreDestroy method not invokved on javax.faces.bean.ViewScoped beans on Session invalidation [MYFACES-4048] - TransientStateHolder values must be stored in the state if current phase is before render response [MYFACES-4049] - JSF myfaces unsynchronized access to a WeakHashMap [MYFACES-4050] - Validators not invoked for empty selectManyCheckbox components [MYFACES-4051] - FacesMessage.Severity always set to ERROR after ValidatorException [MYFACES-4052] - Multiple with same name encodes only last one in link URL [MYFACES-4057] - Serializable ViewScopeContextualStorage references non-serializable BeanManager [MYFACES-4060] - Required attribute of h:inputFile tag is not working Improvement [MYFACES-4046] - Allow programmatic component with ui:include with ui:param Task [MYFACES-4045] - Review Faces Flow reentrant condition regards, Leonardo Uribe
Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope
Hi I'm cc to MyFaces users list, because these issues should be discussed there. It is a known issue, in resume it is JBossWeb fault, because that map should be a WeakHashMap but synchronized, to ensure the instances are discarded when the beans are serialised into session (in that case destroy will not be called). The fix should be done in WebInjectionContainer, but set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION <https://myfaces.apache.org/core20/myfaces-impl/webconfig.html#org_apache_myfaces_SERIALIZE_STATE_IN_SESSION> to false could help to mitigate a bit the leak. There is an issue related to @PreDestroy and view scope in https://issues.apache.org/jira/browse/MYFACES-4047 but I guess it won't help in your case, because the leak is caused by the map itself. regards, Leonardo Uribe 2016-09-01 3:34 GMT-05:00 Thony Lundin <thony.lun...@tieto.com>: > Hi Leonardo, > > writing you since you are MyFaces core project lead and want to ask about > a possible issue in MyFaces 2.2.10 regarding not released viewscope beans. > > I have seen on Internet that there was multiple such issues reported for > mojarra in the past and Red Hat did some fix in their EAP 6.1.1 or > so (in the mojarra module) to solve this issue. > > Problem for us is that we came from using tomcat and went on top of Red > Hat EAP with JBossWeb and wanted to keep MyFaces (since it provided us with > best performance and configuration options) but we are hit by this memory > leak that somehow MyFaces and JBossWeb do not interact properly when a > viewscope bean is getting invalidated. Problem is that when viewscope is > invalidated the reference to our controllers are still kept in JBossWeb > WebInjectionContainer and it is kept there forever, even if session expires? > > org.jboss.as.web.deployment.WebInjectionContainer @ 0xc45318d8 | 32 | > 649,769,928 | 73.07% |- org.jboss.as.web.deployment.ConcurrentReferenceHashMap > @ 0xc4532518 | 48 | 649,766,792 | 73.07% | '- org.jboss.as.web.deployment. > ConcurrentReferenceHashMap$Segment[4] @ 0xc4532548| 32 | 649,766,744 | > 73.07% | |- org.jboss.as.web.deployment.ConcurrentReferenceHashMap$Segment > @ 0xc4532568| 56 | 187,909,296 | 21.13% > > Red Hat will not do anything due to that they only support mojarra so I am > asking if this is something known on MyFaces project and if there is > something that could be done on MyFaces core side about it (just asking > since same problem for JBossWeb was solved somehow on mojarra side) > or if you think this is a JBossWeb fault? > > Grateful for any information you can share on this issue. > > Best Regards, > Thony >
[ANNOUNCE] MyFaces Trinidad v2.1.1 Release
FacesMessageWrapper and Skin Addition enhancements [TRINIDAD-2476] - MApplication.java needs to override subscribeToEvent [TRINIDAD-2496] - Support custom negative prefix and suffix on af:convertNumber [TRINIDAD-2501] - Renderkit Test Improvements [TRINIDAD-2502] - Finish RenderKit Test Improvements so we can always run all tests [TRINIDAD-2507] - Allow CoreRenderer to take part in broadcast of a FacesEvent [TRINIDAD-2510] - make SkinTestCase more extendable [TRINIDAD-2514] - Make isEmailMode check more lenient New Feature [TRINIDAD-2459] - Addition of ValueUpdatedEvent + ValueUpdatedListener regards, Leonardo Uribe
Re: addResource to add CSS JS - Only working on PostBack
Hi Add the resource in afterPhase(...) is too late in the lifecycle, because if the response was flushed the script could not be rendered. Add it in beforePhase(...) of render response should work. Just FYI, ExtensionsFilter class is the one responsible to create the buffer and then parse the response and insert the code. The API was meant to be used in components, but I do not see any reason why it should not work. It could be an old bug that was fixed at some point in time. regards, Leonardo Uribe 2016-04-19 14:14 GMT-05:00 Mike Kienenberger <mkien...@gmail.com>: > I guess it probably doesn't help -- it looks like your phase listener > was already using RENDER_RESPONSE. > > On Tue, Apr 19, 2016 at 3:13 PM, Mike Kienenberger <mkien...@gmail.com> > wrote: > > There is only a RENDER_RESPONSE phase for the initial request in a > > phase listener, but all of the phases in a postback. > > > > Does that help? > > > > > > On Tue, Apr 19, 2016 at 2:09 PM, fischman_98 > > <mfisc...@powerconsultantsinc.com> wrote: > >> *FYI*: When added the call to addResource in encodeEnd method of a > Custom > >> Component it works on both /*initial request*/ and /*postback */. > >> > >> Here's the initial request; > >> > >> RESTORE_VIEW(1) :: Before > >> RESTORE_VIEW(1) :: After > >> RENDER_RESPONSE(6) :: Before > >> *AddResource Here!* > >> RENDER_RESPONSE(6) :: After > >> > >> Same code I had in the listener in the encodeEnd; > >> > >> AddResource ar = AddResourceFactory.getInstance(facesContext); > >> ar.addInlineScriptAtPosition(facesContext, > AddResource.HEADER_BEGIN, > >> "window.open()"); > >> System.out.println("AddResource Here!"); > >> > >> Soany thoughts why it works from the component and not from the > phase > >> listener? > >> > >> Thanks. > >> > >> > >> > >> > >> -- > >> View this message in context: > http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593p121619.html > >> Sent from the MyFaces - Users mailing list archive at Nabble.com. >
Re: addResource to add CSS JS - Only working on PostBack
Hi AddResource API in its default implementation use a buffer to render resources, but on render response phase, so you should aim to add your resources in that phase. A custom phase listener or a custom component using the code in encodeXXX should work. Regards, Leonardo On Apr 19, 2016 8:05 AM, "fischman_98"wrote: > So are you confirming/agreeing that the result of an addResource call is > handled in the Apply Request phase? > > And as to /only need to adjust the code a bit/, what code and where? I was > trying in a phaselistener, are you suggesting a custom ViewHandler, custom > component or ? > > Matt > > > > -- > View this message in context: > http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593p121611.html > Sent from the MyFaces - Users mailing list archive at Nabble.com. >
Re: addResource to add CSS JS - Only working on PostBack
Hi "apply request value" phase is invoked on postback only. In the initial request, only 2 phases are executed: restore view phase and render view phase. Probably you only need to adjust the code a bit. regards, Leonardo Uribe 2016-04-14 21:31 GMT-05:00 fischman_98 <mfisc...@powerconsultantsinc.com>: > To all, > > I still have a MyFaces 1.1.6/Tomahawk 1.1.10 in production, client not > giving the time to migrate to 2.X. > > That said, I'm trying to add javascript to specific pages section (security code to stop the page from being included in frames; href="https://www.owasp.org/index.php/Cross_Frame_Scripting > ">Cross_Frame_Scripting > ). > > Instead of just adding it to the pages between > tags, I am trying to use org.apache.myfaces.renderkit.html.util.AddResource > to inject the CSS and JS (/analyze the directories and add it to specific > pages/). > > I thought to do it in a phaseListener. > > Problem is, I can't get it to work on the *initial reques*t, only on > *PostBacks* (/is it done in the *Apply Requests* phase/?). > > Seems like I should be able to intercept the response and add this...I have > the Extensions Filter (Tomahawk) set up and have added ADD_RESOURCE_CLASS > (DefaultAddResource) to the context in web.xml. > > Anyone have any thoughts? > > I haven't posted a question in a long while...I would love to hear a > solution for this (/relatively/) Old School set up! > > Thanks. > > > > > > > > -- > View this message in context: > http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593.html > Sent from the MyFaces - Users mailing list archive at Nabble.com. >
[ANNOUNCE] MyFaces Core v2.2.10 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.10. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.10 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.2.10 Bug [MYFACES-3904] - jsf.util.Chain() is rendered with wrong event source [MYFACES-3905] - The caption facet is not documented for the tag . [MYFACES-3926] - Disabled h:outputLink renders invalid attributes [MYFACES-3959] - f:metadata inside ui:remove will be also executed [MYFACES-3987] - NPE in FlashImpl.isKeepMessages [MYFACES-4022] - Faces Flows are not discovered when the web application is packaged inside an EAR [MYFACES-4024] - Update the NOTICE.txt file in jsf.myfaces [MYFACES-4025] - Incorrect JS content-type [MYFACES-4030] - MyFaces CDI support is disabled if non-CDI application is loaded first [MYFACES-4031] - Facelets does not render empty XHTML attribute [MYFACES-4032] - upgrade common-beanutils to 1.9.2 [MYFACES-4034] - submitForm() not defined for myfaces.JSF_JS_MODE 'minimal-modern' [MYFACES-4038] - Flow beans are destroyed before flow is finalized [MYFACES-4041] - EL evaluation fails when state is saved because FaceletState object is not present Improvement [MYFACES-3497] - [perf] Improve EventHandler [MYFACES-3552] - [perf] pps: reduce amout of Object [] created in _DeltaList.saveState [MYFACES-3892] - Create a option to execute BeanValidation before JSF-Validation [MYFACES-4027] - Increase import range for javax.el-api to include version 3.0 of javax.el-api [MYFACES-4042] - Improve startup time by skipping classpath jar scan for *.faces-config.xml Task [MYFACES-4020] - Update commons-collections to 3.2.2 regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.1.18 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.1.18. MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.1.18 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.1.18 Bug [MYFACES-3233] - f:ajax event - type="javax.el.ValueExpression (must evaluate to java.lang.String)" not supported [MYFACES-3949] - javax.faces.ViewState autocomplete [MYFACES-3951] - Action not performed on first click [MYFACES-3957] - Disabled h:commandLink results in rendering of a span with onclick [MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent [MYFACES-3965] - SKIP_ITERATION visit hint not set when component tree is visited during navigation [MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception [MYFACES-4025] - Incorrect JS content-type [MYFACES-4031] - Facelets does not render empty XHTML attribute regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.0.24 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.24. MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.24 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.0.24 Bug [MYFACES-3949] - javax.faces.ViewState autocomplete [MYFACES-3951] - Action not performed on first click [MYFACES-3957] - Disabled h:commandLink results in rendering of a span with onclick [MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent [MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception [MYFACES-4025] - Incorrect JS content-type regards, Leonardo Uribe
Re: FW: Tomcat Security Exceptions on deployment of example war (reformatted)
Hi I think the problem here is that it is not clear what needs to be fixed. Looking on the stack trace and in the code: protected JspFactory getJspFactory() { if (jspFactory == null) { // TODO: this Class.forName will be removed when Tomcat fixes a bug // also, we should then be able to remove jasper.jar from the deployment try { Class.forName("org.apache.jasper.compiler.JspRuntimeContext"); } catch (ClassNotFoundException e) { // ignore } catch (Exception ex) { log.log(Level.FINE, "An unexpected exception occured " + "while loading the JspRuntimeContext.", ex); } jspFactory = JspFactory.getDefaultFactory(); } return jspFactory; } These lines are very old. Looking on the svn it comes from 1.2.x, see: https://issues.apache.org/jira/browse/MYFACES-1693 Probably the solution could be catch a Throwable instead an Exception and swallow it (just log but continue startup). I mean, this line looks like something done by some reason long time ago by a bug in Tomcat. It is clear the security manager is causing trouble in this case, but since JSP was deprecated since JSF 2.0, should we worry about this one? Please note there is a web config param called org.apache.myfaces.FACES_INITIALIZER that allows you to bypass the default initializer and provide a custom one (so you can copy the default initializer and customize it to your needs), or set org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL disable JSP and uses org.apache.myfaces.webapp.FaceletsInitilializer instead. There are plenty of options to deal with this issue. Please try the options I have described here and let us know if that works for you or not, so if necessary we can fix the lines if necessary. regards, Leonardo Uribe 2016-03-30 11:40 GMT-05:00 Neil Richards <neilricha...@iname.com>: > OK thanks :) > > -Original Message- > From: Mike Kienenberger [mailto:mkien...@gmail.com] > Sent: 30 March 2016 16:47 > To: MyFaces Discussion <users@myfaces.apache.org> > Subject: Re: FW: Tomcat Security Exceptions on deployment of example war > (reformatted) > > MyFaces is a project staffed by volunteers. While things are > normally fixed rather quickly, it all depends on the various individuals > involved with that particular area and their available free time. > > One thing that would greatly speed up the process is if you were to submit > a unified diff patch fixing the problem. > > On Wed, Mar 30, 2016 at 11:28 AM, Neil Richards <neilricha...@iname.com> > wrote: > > Hi, > > > > As you can imagine this has become a bit of a showstopper for me. I've > > added a bug report but as yet it has not been assigned or commented on > > etc. Just wondering how long these issues take to fix? Assume we're > talking months? > > Need to have some idea to determine how to move forward. > > > > Many thanks, > > Neil > > > > -Original Message- > > From: Werner Punz [mailto:werner.p...@gmail.com] > > Sent: 04 March 2016 07:36 > > To: users@myfaces.apache.org > > Subject: Re: FW: Tomcat Security Exceptions on deployment of example > > war > > (reformatted) > > > > Hi this is clearly a bug. > > Can you please put a bugreport on > > > > https://issues.apache.org/jira/browse/MYFACES > > > > Werner > > > > > > > > Am 02.03.16 um 23:12 schrieb Neil Richards: > >> Hi, > >> > >> I've been having trouble deploying my MyFaces(2.2.9) app on Tomcat 8 > >> with the security manager enabled, so I then tried deploying the > >> myfaces-example-simple-1.1.14.war and had the same problem. I need > >> the security manager enabled as I am deploying in production on a > >> shared > > Tomcat > >> instance and the hosts will not allow the RuntimePermissions on > >> org.apache.catalina.core, org.apache.catalina.servlets or > >> org.apache.jasper.compiler. These are the stack traces I get: > >> > >> 02-Mar-2016 22:08:54.902 INFO [localhost-startStop-1] > >> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security > >> Violation, attempt to use Re stricted Class: > >> org.apache.catalina.servlets.DefaultServlet > >> java.security.AccessControlException: access denied > >> ("java.lang.RuntimePermission" > >> "accessClassInPackage.org.apache.catalina.servlets") > >> at > >> java.security.AccessControlContex
Re: bug in FacesServlet?
Hi It could be possible, I do not have all the details, but I have the impression that happens on jsp, or at least I have seen that before. MyFaces does what the spec says, but this part could not be well defined. It is clear the release should happen after the end of the lifecycle, but since the rendering step is delegated to jsp in this case, after that point there is no control, so the code just release in that point. The problem here is we don't know what happens for different jsp containers. In my understanding not every jsp implementation works the same, but as I said, I have not entered into details. regards, Leonardo Uribe 2016-03-25 13:15 GMT-05:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > Hi guys, > > org.apache.myfaces.context.servlet.FacesContextImpl#release does the > release but javax.faces.webapp.FacesServlet#service doesn't handle > context push/pop so if a JSF request does a JSF include (and retrigger > the servlet) it will likely reset too early the context. > > Here a diagram hoping it helps: > > -> request > -> FacesServlet > -> setFacesContext > -> FacesServlet > -> anything relaunching a JSF "request" > org.apache.myfaces.view.jsp.JspViewDeclarationLanguage#buildView does > a forward for instance) > -> setFacesContext > -> setFacesContext > -> releaseFacesContext > -> end of lifecycle // oops faces context is null > -> releaseFacesContext > > Romain Manni-Bucau > @rmannibucau | Blog | Github | LinkedIn | Tomitriber >
Re: No tag defined for name
Hi Have you tried this web config param? org.apache.myfaces.STRICT_JSF_2_ALLOW_SLASH_LIBRARY_NAME set it to true. It was added on this issue: https://issues.apache.org/jira/browse/MYFACES-3454 regards, Leonardo Uribe 2015-12-17 12:34 GMT-05:00 Mike Kienenberger <mkien...@gmail.com>: > It looks right to me. > > Is "commons/paging.xhtml" the only component not working? > Do other components in "components/commons/" work? > Do other components in "components" work? > > > My app uses .../resources/component/thing.xhtml" but moving "thing.xhtml" > to "component/common" seems to still work. I didn't try renaming > "component" to "components" and I suppose my test of the process may have > been flawed. This was under MyFaces 2.1.14. > > Maybe creating a simple test app would help you track it down, or at least > provide an example to use for opening a JIRA issue. It'd be helpful to > know if it's only a problem with MyFaces 2.2.x or if it wasn't working for > you under 2.1.x either. > > On Thu, Dec 17, 2015 at 10:40 AM, Chris Baumgartner < > chris.baumgart...@fujifilm.com> wrote: > > > Hello, > > > > I have a JSF application that has been using Mojarra for the past 2 > > years. I am attempting to switch to MyFaces 2.2.9, but I am having > > problems. > > > > It doesn't seem to like my composite components. I am getting numerous > > exceptions like: > > > > javax.faces.view.facelets.TagException: /views/records/records.xhtml > > @81,57 Tag Library supports namespace: > > http://java.sun.com/jsf/composite/components/common, but no tag was > > defined for name: paging > > > > This worked in Mojarra, but for some reason is not working in MyFaces. > > > > My namespace declarations in records.xhtml look like: > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;> > > http://www.w3.org/1999/xhtml; > > xmlns:c="http://java.sun.com/jsp/jstl/core; > > xmlns:common=" > http://java.sun.com/jsf/composite/components/common > > " > > xmlns:h="http://java.sun.com/jsf/html; > > xmlns:f="http://java.sun.com/jsf/core; > > xmlns:ui="http://java.sun.com/jsf/facelets;> > > > > > > > > My project structure looks like: > > > > webapp/resources/components/common/paging.xhtml > > webapp/templates/template.xhtml > > webapp/views/records/records.xhtml > > > > > > Any ideas on what is causing this? > > > > Thanks. > > > > > > -- > > > > Chris Baumgartner > > Java Software Developer > > FUJIFILM Medical Systems U.S.A., Inc. > > TeraMedica Division > > 10400 Innovation Drive, Suite 200 > > Milwaukee, WI 53226 > > Office: (414) 908-7724 > > www.teramedica.com > > > > -- > > NOTICE: This message, including any attachments, is only for the use of > the > > intended recipient(s) and may contain confidential and privileged > > information, or information otherwise protected from disclosure by law. > If > > the reader of this message is not the intended recipient, you are hereby > > notified that any use, disclosure, copying, dissemination or distribution > > of this message or any of its attachments is strictly prohibited. If you > > received this message in error, please contact the sender immediately by > > reply email and destroy this message, including all attachments, and any > > copies thereof. > > >
[ANNOUNCE] MyFaces Core v2.2.9 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.9. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.9 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID "org.apache.myfaces.core". Release Notes - MyFaces Core - Version 2.2.9 Bug [MYFACES-3957] - Disabled h:commandLink results in rendering of a span with onclick [MYFACES-3978] - NullPointerException in FaceletStateValueExpression when ViewPooling enabled [MYFACES-3980] - c:forEach varStatus is assigned with the wrong base [MYFACES-3981] - Unable to resolve Integer API as Lambda expression in a facelet [MYFACES-3982] - javax.faces.context.ExternalContext#getInitParameter should throw NPE when name is null [MYFACES-3983] - ViewScopeBinding does not work, results in an exception when using a datatable [MYFACES-3986] - viewScope implicit object not resolved in a JSP page [MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception [MYFACES-3989] - MalformedURLException when javax.faces.FACELETS_LIBRARIES contains line feed [MYFACES-3992] - f:ajax doesn't append javax.faces.ViewState back on re-render of form in stateless view [MYFACES-3996] - Value of HTML-Attribute class on Passthrough element is casted to java.lang.Class if coming from EL [MYFACES-4000] - Some MyFaces JSF 2.2 API signatures do not match the Java EE 7 API [MYFACES-4003] - Allow the "class" Attribute To Be Set For Custom Tags [MYFACES-4008] - AbstractMethodError thrown by javax.servlet.http.Part.getSubmittedFileName() [MYFACES-4010] - MyFaces 2.2 throws UnsupportedOperationException with an eager ManagedBean with ManagedProperty [MYFACES-4016] - Error when submitting an Ajax request for an element without an ID [MYFACES-4017] - custom expression factory not correctly loaded [MYFACES-4019] - Updating a bound value not possible if input component is within c:forEach Improvement [MYFACES-3063] - code cleanup and performance review [MYFACES-3985] - [perf] avoid field initialization on CDI beans [MYFACES-4001] - Outdated java.sun.com XML namespaces in 2.2 tagdoc [MYFACES-4014] - Log required startup time [MYFACES-4015] - [perf] provide annotation scanning via CDI extension Task [MYFACES-4005] - Classloading conflict with httpclient (update commons-codec to 1.10) regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.8 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.8. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.8 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.8 Bug [MYFACES-3233] - f:ajax event - type=javax.el.ValueExpression (must evaluate to java.lang.String) not supported [MYFACES-3947] - Passthrough Element textarea doesn't work [MYFACES-3948] - Wrong check of facelets libraries last modification time in FacesConfigurator [MYFACES-3949] - javax.faces.ViewState autocomplete [MYFACES-3951] - Action not performed on first click [MYFACES-3956] - ResourceHandler.libraryExists(...) does not work for resource library contracts [MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent [MYFACES-3964] - c:foreach not working when using custom equals or non serializable objects [MYFACES-3965] - SKIP_ITERATION visit hint not set when component tree is visited during navigation [MYFACES-3966] - Setting oamEnableViewPool=false causes NullPointerException in ViewPoolProcessor.pushPartialView() [MYFACES-3967] - View Pooling - ViewScope missing for Static Structure Views [MYFACES-3969] - Flow initalizer called before inbound parameters are set [MYFACES-3970] - 11.4.2.1 topic Each contract-mapping element can have one or more contract elements. [MYFACES-3973] - partial-response element does not contain an id attribute [MYFACES-3974] - Ajax delay attribute with a value of none does not work [MYFACES-3975] - PreClearFlashEvent called on every JSF request regardless of Flash use [MYFACES-3976] - f:viewAction phase attribute reverts to INVOKE_APPLICATION [MYFACES-3977] - 12.1.3 add this text to the javax.faces.STATE_SAVING_METHOD spec. When examining the value, the runtime must ignore the case. Improvement [MYFACES-3954] - [perf] Use ResourceLoaderCache for ResourceHandler.libraryExists(...) regards, Leonardo Uribe
Re: EL 3.0 Static Field References
Hi I think it is a bug in JSF 2.2 spec. The behavior for ScopedAttributeELResolver (for facelets) is defined in section 5.6.2.9. To solve it (for 2.3) you should raise an issue on: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC But I found this one already created on Mojarra issue tracker: https://java.net/jira/browse/JAVASERVERFACES-3362 Please create an issue on the spec issue tracker. MyFaces already has some params to control the EL Resolver ordering, so I suppose this feature will help to fix the problem for 2.2.x. Besides that, we can't do anything else from this side. regards, Leonardo Uribe 2015-03-27 9:19 GMT-05:00 William Lucy wtl...@us.ibm.com: Thanks for the response, Leonardo. From what I can tell, the issue isn't that MyFaces can't find the StaticFieldELResolver - that is loaded correctly. JSP static field EL references do work properly through MyFaces, so there does seem to be some JSF issue. I think there may be a spec issue here? (What I believe to be) a similar issue had to be addressed for JSP 2.3: https://bz.apache.org/bugzilla/show_bug.cgi?id=57141 MyFaces has a resolver, ScopedAttributeResolver, which always sets the resolved field on the EvaluationContext to true if the EL expression's property isn't null. The issue with that is when we're trying to resolve the EL expression base (eg. Boolean in the expression Boolean.TRUE) EL 3.0 never has a chance to resolve the import the base ELClass, since it first runs through the EL Resolvers. My testing has shown that if we don't set context.setPropertyResolved(true) in the ScopedAttributeResolver, this particular case (#{Boolean.TRUE}) works as expected. Any thoughts on this? Let me know if I need to clarify anything. Regards, Bill Lucy Leonardo Uribe lu4...@gmail.com wrote on 03/25/2015 06:10:00 PM: From: Leonardo Uribe lu4...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Date: 03/25/2015 06:11 PM Subject: Re: EL 3.0 Static Field References Hi It is in the spec, it should work. There is some code in org.apache.myfaces.el.unified.ResolverBuilderForFaces that deals with this: if (STATIC_FIELD_EL_RESOLVER_CLASS != null GET_STREAM_EL_RESOLVER_METHOD != null) { try { ELResolver streamElResolver = (ELResolver) GET_STREAM_EL_RESOLVER_METHOD.invoke( getRuntimeConfig().getExpressionFactory()); if (streamElResolver != null) { // By default return null, but in a EL 3 implementation it should be there, // this is just to avoid exceptions in junit testing list.add(streamElResolver); } list.add((ELResolver) STATIC_FIELD_EL_RESOLVER_CLASS.newInstance()); } The code checks for javax.el.StaticFieldELResolver class and ExpressionFactory.getStreamELResolver(...) method before add both EL resolvers. If MyFaces jars cannot locate these classes, the EL resolvers are not loaded (because it assumes EL 3.0), and the described behavior will happen. regards, Leonardo Uribe 2015-03-25 15:14 GMT-05:00 William Lucy wtl...@us.ibm.com: Hi All, I'm running into some issues trying to test the EL 3.0 functionality on MyFaces 2.2.7 + Tomcat 8.0.16. My understanding is that we should be able to reference static fields/methods directly from facelets, eg. Boolean.TRUE test: [h:outputText id=out2 value=#{Boolean.TRUE}/] should return Boolean.TRUE test: [true]. This isn't the case, however; no value is returned, and nothing's logged. Additionally, when I try to access a static field on a local ManagedBean, I get ... javax.el.PropertyNotFoundException: Property 'staticReference' not found on type beans.EL30StaticFieldsAndMethodsBean at javax.el.BeanELResolver$BeanProperties.get (BeanELResolver.java:244) at javax.el.BeanELResolver$BeanProperties.access$300 (BeanELResolver.java:221) at javax.el.BeanELResolver.property(BeanELResolver.java:331) at javax.el.BeanELResolver.getValue(BeanELResolver.java:95) at javax.el.CompositeELResolver.getValue (CompositeELResolver.java:66) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue (FacesCompositeELResolver.java:179) ... 1 more Where the ManagedBean is defined simply as package beans; import javax.faces.bean.ApplicationScoped; import javax.faces.bean.ManagedBean; @ManagedBean(name = staticbean) @ApplicationScoped public class EL30StaticFieldsAndMethodsBean { ... public static final String staticReference = static reference; ... } Has anyone else tried working with these kinds of EL 3.0 features
Re: Issues using View Pooling - ViewScope is missing for static structure views?
Hi I was able to reproduce the problem. Thanks for the log, it helped a lot to understand what's going on. It looks like the call to restoreState was overriding view scope, so the fix done was add some lines to check that case and avoid it. I added some junit tests and on the way I fixed a small issue with view root metadata facet. I hope these fixes will solve your problem. Let us know if that is the case or not. regards, Leonardo Uribe 2015-03-24 16:39 GMT-05:00 Chris Kulinski chriskulin...@yahoo.com: Leonardo - Thanks for the research and updated cases on the patch. We'll apply your recent changes to our testing and try again. Unfortunately, the additional fixes for this defect didn't fix our other defect with missing View Scope. I'll create a new issue in the issue tracker to watch this. We'll work on assembling a simple demo that shows the problem. The issue might happen because the View Pooling code doesn't always run during RESTORE_VIEW phase. It only seems to run in RESTORE_VIEW for AJAX post-backs. Any changes to our ViewScope objects that happen before RENDER_RESPONSE are lost because it looks like the ViewScope is sometimes reattached at RENDER_RESPONSE. We've added manual debugging to the MyFaces source to attempt to show the problem. Does this help enough to troubleshoot what's happening? On the very first request to the view after application startup, the behavior is correct. I guess this is because the View hasn't been flushed and remapped by the pool yet. There is a second instance of the Bean created, but that's maybe after the view is rendered (in saveViewRootState, storeStatic and pushStaticStructureView). 2015-03-24 16:48:23,235 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1) Start Phase RESTORE_VIEW(1) 2015-03-24 16:48:23,374 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1) End Phase RESTORE_VIEW(1) 2015-03-24 16:48:23,400 INFO [stdout] (default task-1) HelloCdiTwoScopedBean - constructed new instance 2015-03-24 16:48:23,406 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1) Start Phase RENDER_RESPONSE(6) 2015-03-24 16:48:23,420 INFO [stdout] (default task-1) POOLING: retrieveStaticStructureMetadata root:/examples/ajaxsamples/helloAjax.xhtml key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892 2015-03-24 16:48:23,420 INFO [stdout] (default task-1) POOLING: retrieveStaticStructureMetadata metadatanull 2015-03-24 16:48:23,505 INFO [stdout] (default task-1) POOLING root:/examples/ajaxsamples/helloAjax.xhtml dynamic:false 2015-03-24 16:48:23,505 INFO [stdout] (default task-1) POOLING: saveViewRootState root:/examples/ajaxsamples/helloAjax.xhtml 2015-03-24 16:48:23,506 INFO [stdout] (default task-1) POOLING: storeStatic root:/examples/ajaxsamples/helloAjax.xhtml keyorg.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892 2015-03-24 16:48:23,551 INFO [stdout] (default task-1) HelloCdiTwoViewScopedBean - constructed new instance 2015-03-24 16:48:23,681 INFO [stdout] (default task-1) POOLING: pushStaticStructureView key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892 entry:org.apache.myfaces.view.facelets.pool.impl.SoftViewEntry@27ed7f 2015-03-24 16:48:23,683 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1) End Phase RENDER_RESPONSE(6) On the next request, Pooling isn't executed until during RENDER_RESPONSE. This bean is created after RESTORE_VIEW, but before RENDER_RESPONSE (via PrettyFaces). The view is using a 2nd instance of the Bean for rendering, without the values from the initial instance (after popStaticStructureView). 2015-03-24 17:18:51,090 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6) Start Phase RESTORE_VIEW(1) 2015-03-24 17:18:51,091 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6) End Phase RESTORE_VIEW(1) 2015-03-24 17:18:51,093 INFO [stdout] (default task-6) HelloCdiTwoScopedBean - constructed new instance 2015-03-24 17:18:51,094 DEBUG [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6) Start Phase RENDER_RESPONSE(6) 2015-03-24 17:18:51,094 INFO [stdout] (default task-6) POOLING: retrieveStaticStructureMetadata root:/examples/ajaxsamples/helloAjax.xhtml key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892 2015-03-24 17:18:51,094 INFO [stdout] (default task-6) POOLING: retrieveStaticStructureMetadata metadataorg.apache.myfaces.view.facelets.pool.impl.ViewStructureMetadataImpl@15744d1 2015-03-24 17:18:51,094 INFO [stdout] (default task-6) POOLING: popStaticStructureView key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892 q:org.apache.myfaces.view.facelets.pool.impl.ViewPoolEntryHolder@672a58 2015-03-24 17:18:51,098 INFO [stdout] (default
Re: EL 3.0 Static Field References
Hi It is in the spec, it should work. There is some code in org.apache.myfaces.el.unified.ResolverBuilderForFaces that deals with this: if (STATIC_FIELD_EL_RESOLVER_CLASS != null GET_STREAM_EL_RESOLVER_METHOD != null) { try { ELResolver streamElResolver = (ELResolver) GET_STREAM_EL_RESOLVER_METHOD.invoke( getRuntimeConfig().getExpressionFactory()); if (streamElResolver != null) { // By default return null, but in a EL 3 implementation it should be there, // this is just to avoid exceptions in junit testing list.add(streamElResolver); } list.add((ELResolver) STATIC_FIELD_EL_RESOLVER_CLASS.newInstance()); } The code checks for javax.el.StaticFieldELResolver class and ExpressionFactory.getStreamELResolver(...) method before add both EL resolvers. If MyFaces jars cannot locate these classes, the EL resolvers are not loaded (because it assumes EL 3.0), and the described behavior will happen. regards, Leonardo Uribe 2015-03-25 15:14 GMT-05:00 William Lucy wtl...@us.ibm.com: Hi All, I'm running into some issues trying to test the EL 3.0 functionality on MyFaces 2.2.7 + Tomcat 8.0.16. My understanding is that we should be able to reference static fields/methods directly from facelets, eg. Boolean.TRUE test: [h:outputText id=out2 value=#{Boolean.TRUE}/] should return Boolean.TRUE test: [true]. This isn't the case, however; no value is returned, and nothing's logged. Additionally, when I try to access a static field on a local ManagedBean, I get ... javax.el.PropertyNotFoundException: Property 'staticReference' not found on type beans.EL30StaticFieldsAndMethodsBean at javax.el.BeanELResolver$BeanProperties.get (BeanELResolver.java:244) at javax.el.BeanELResolver$BeanProperties.access$300 (BeanELResolver.java:221) at javax.el.BeanELResolver.property(BeanELResolver.java:331) at javax.el.BeanELResolver.getValue(BeanELResolver.java:95) at javax.el.CompositeELResolver.getValue (CompositeELResolver.java:66) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue (FacesCompositeELResolver.java:179) ... 1 more Where the ManagedBean is defined simply as package beans; import javax.faces.bean.ApplicationScoped; import javax.faces.bean.ManagedBean; @ManagedBean(name = staticbean) @ApplicationScoped public class EL30StaticFieldsAndMethodsBean { ... public static final String staticReference = static reference; ... } Has anyone else tried working with these kinds of EL 3.0 features? Or am I possibly just missing something here? Thanks, Bill Lucy
Re: Issues using View Pooling - ViewScope is missing for static structure views?
Hi Thanks for your kind words about the view pooling algorithm :-). It looks there are two issues here. - Add null check on pushPartialView(...) : The solution is correct, I'll commit it soon. - View scope not restored correctly on static structure views : I have not been able to reproduce the problem (it works for me with the latest code, and I do not see a bug in the code). The algorithm used to deal with static/partial and the algorithm for dynamic views has some differences, so it should be something very specific that activates the problem. If you can provide a simple demo that shows the problem, that would be very helpful. The problem with these kind of issues is they are usually really hard to debug, because reproduce them can be very difficult. Anyway, please open a new issue on myfaces issue tracker, so we can keep track on this. regards, Leonardo Uribe 2015-03-22 20:04 GMT-05:00 Chris Kulinski chriskulin...@yahoo.com.invalid: We're testing the View Pooling features of MyFaces 2.2.x on a large pre-existing JSF site with very complex and heavy views with lots of composite components. The performance improvement is frankly amazing - we've gone from GC events every few seconds under heavy load to virtually no GC events at all... Kudos to Leonardo for building in this feature! We've encountered one specific issue - a NullPointerException when using oamEnableViewPool=false to disable pooling for specific views. We've created https://issues.apache.org/jira/browse/MYFACES-3966 for this issue. We needed to disable pooling for certain views because we noticed issues with static structure views when using ViewScope. Our ViewScope beans are available in our controller code, but are no longer available during the Render Response phase in our xhtml pages - via expression language lookups. - On the very first request to the view (before its placed in the pool), the state is applied correctly - but then every subsequent request to the pooled view doesn't have the correct view state. - It looks like the view state hasn't been correctly applied on the view after its retrieved from the pool. Ways we've been able to work around this issue: - If we disable view pooling for these views, then the beans are correctly available in ViewScope. - We don't see this issue on any of our dynamic structure views - in fact, if we convert the static structure view to a dynamic structure view (via an extra ui:include with EL, etc), then the view state is mapped correctly and the viewscope beans are available. There must some pooling state restore logic that's missing from static structure logic? Has anyone else seen this issue? Or has anyone implemented view pooling with static and dynamic structure views and view scope? Thanks!Chris Kulinski
[ANNOUNCE] MyFaces Core v2.0.23 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.23. MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.23 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.0.23 Bug [MYFACES-3930] - java.lang.IllegalArgumentException: null at HtmlRenderKitImpl.createResponseWriter [MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet = NullPointerException [MYFACES-3935] - h:inputTextarea with null value throws NullPointerException [MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle SE8 .class files properly regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.1.17 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.1.17. MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.1.17 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.1.17 Bug [MYFACES-3928] - MyFaces doesn't resolve in OSGi environment when Servlet API 3.1 is present [MYFACES-3930] - java.lang.IllegalArgumentException: null at HtmlRenderKitImpl.createResponseWriter [MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet = NullPointerException [MYFACES-3935] - h:inputTextarea with null value throws NullPointerException [MYFACES-3941] - FaceletCacheImpl#isFaceletCached(URL) always returns false [MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle SE8 .class files properly regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.7 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.7. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.7 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.7 Bug [MYFACES-3929] - Update org.apache.myfaces.CONFIG_REFRESH_PERIOD to JSF 2.2 [MYFACES-3940] - FlowScopeBeanHolder calls ApplicationContextBean on PreDestroy [MYFACES-3941] - FaceletCacheImpl#isFaceletCached(URL) always returns false [MYFACES-3942] - f:viewParam binding causes NPE because UIViewRoot is null [MYFACES-3944] - Calls to fcc.startComponentUniqueIdSection(...) and fcc.endComponentUniqueIdSection(...) should be surrounded in a try finally block [MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle SE8 .class files properly [MYFACES-3946] - Ajax listener on JsfElement components not invoked regards, Leonardo Uribe
Re: javax.faces.ViewState autocomplete
Hi Yes, it could be considered a bug. But it looks strange to set it on a hidden field. Anyway, the argumentation is solid, so please create an issue. It could be great if you can say in which browsers this behavior happens. regards, Leonardo Uribe 2015-01-13 14:31 GMT-05:00 Werner Punz werner.p...@gmail.com: Am 09.01.15 um 11:58 schrieb Dan Østerberg: Hi, We have a JSF application where we mainly use ViewScoped beans, and add no-cache headers for all JSF pages. Navigating back to a previous page correctly recreates the beans, and renders new HTML, with a new ViewState ID. But... some browsers autocomplete some of the hidden ViewState inputs, overriding the new value with an old ViewState value. We have verified this in the browser dev-tools by looking at the response, which is correct, and the resulting HTML which is not. In short, this is a known autocomplete issue, which Mojarra has fixed since 1.2, by adding 'autocomplete=off' to the hidden ViewState input. Plus a context parameter com.sun.faces.autoCompleteOffOnViewState for opting not to use it, since it results in invalid XHTML. Adding 'pa:autocomplete=off' explicitly to the whole form also fixes this issue. However, at least the MyFaces version that we use (2.2.4) doesn't add this attribute, and doesn't seem to have any corresponding configuration either. We also failed to google up alternatives/explanations for this issue explicitly in MyFaces. Naturally, we would like to avoid javascript hacks and custom components and renderers. So the question is - are we missing something? Or should MyFaces be patched to simply render 'autocomplete=off' for its hidden javax.faces.ViewState inputs? Thanx, Dan Østerberg Hi this looks like a bug to me, please file a bugreport in the MyFaces Bugtracker. https://issues.apache.org/jira/browse/myfaces Kind regards Werner Punz
Re: [Ljava.lang.Object; cannot be cast to javax.faces.component._DeltaList
Hi There is a problem with the id generation, already fixed on: https://issues.apache.org/jira/browse/MYFACES-3944 Probably this case is related too. regards, Leonardo Uribe 2014-11-30 10:10 GMT-05:00 Donatas Čiukšys donatas.ciuk...@mitsoft.lt: I‘m on TomEE 1.7.1, MyFaces 2.2.6, PrimeFaces 5.1.5. Log’s are currently exploding with the error messages like one at the bottom. The page /portal/legalAct is using templating; many ui:decorate that are using many ui:decorate again; often ui:decorate template is like this: ui:decorate template=/WEB-INF/templates/legalActSideALinkedDocuments.xhtml ui:param name=linkTypeCodeParam value=#{LinkTypeHolder.LINK_KEIČIANTIS_PAKEITIMAS_TYPE_CODE}/ ui:param name=linkedDocumentsParam value=#{legalActController.keičiantisPakeitimasDocuments}/ /ui:decorate legalActSideALinkedDocuments.xhtml: ui:composition … p:tab disabled=#{legalActController.linkedDocumentCount lt 0} rendered=#{legalActController.linkedDocumentCount lt 0 or !empty linkedDocumentsParam} ... /p:tab /ui:composition That is, included (decorated actually) part might not be rendered at all. Only ui:composition and ui:decorate are used, no c:if (c namespace is not used at all), no ui:include, no ui:fragment. I think this is some corner case (bug actually). What should I look for (print for debugging) to help find the reason? ERROR 2014-11-30 16:52:12,343 # REQUEST ANALYSIS #: method: POST, requestURL: https://www.e-tar.lt/portal/legalAct.html?documentId=cdba6b00e56911e39ea8c7e1dfdc4b5c, JSF-PHASE: RESTORE_VIEW, AJAX: true, sessionId: C77CE1B76CD9A3435E444B6E243C1096.asHost1 java.lang.IllegalStateException: Error restoring component: mainForm:accordionRight at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:832) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:412) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.application.StateManagerImpl.restoreView(StateManagerImpl.java:133) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:104) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2140) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:336) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.ocpsoft.rewrite.faces.RewriteViewHandler.restoreView(RewriteViewHandler.java:102) ~[rewrite-integration-faces-2.0.12.Final.jar:2.0.12.Final] at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper..java:82) ~[myfaces-api-2.2.6.jar:2.2.6] at org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:66) ~[omnifaces-1.8.1.jar:1.8.1-20140603] at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper..java:82) ~[myfaces-api-2.2.6.jar:2.2.6] at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:170) ~[myfaces-impl-2.2.6.jar:2.2.6] at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196
Re: Unexpected behaviour of duplicate id check algorithm
Hi The only change that could cause like that between 2.1.x and 2.2.x is: https://issues.apache.org/jira/browse/MYFACES-3811 Fix c:forEach behavior once for all The previous algorithm (in 2.1.x) caused problems when you try combinations of c:forEach and ui:include and other tags, so in that sense the new algorithm is more stable. The new algorithm is activated when c:forEach iterates over a Serializable collection, so one way to use the old algorithm from 2.1.x is use a non Serializable collection. The stack trace shows that you are doing something very unusual in you page. The id shouln'd be that long: j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_ 1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_ 0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_ 17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 It should be something that cause the id to be generated in that way, maybe a hidden exception or something inside the iterated components. I see that do the iteration by c:forEach should be surrounded by a try{...} finally{...} block to avoid that situation. I suggest you to check with a debugger how c:forEach is being called. I have created this issue: https://issues.apache.org/jira/browse/MYFACES-3944 - Calls to fcc.startComponentUniqueIdSection(...) and fcc.endComponentUniqueIdSection(...) should be surrounded in a try finally block To deal with this, but that small fix will not solve the real cause of the problem you have. regards, Leonardo Uribe 2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de: Hi, I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and getting strange exception now, stating, that smth. wrong with ids on the page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING parameter value. With javax.faces.PARTIAL_STATE_SAVING set to false: java.lang.IllegalStateException: Client-id : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1 is duplicated in the faces tree. Component : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1, path: {Component-Path : [Class: org.apache.myfaces.extensions.validator.core.factory.ExtValViewRoot,ViewId: /pages/query/query_main.xhtml][Class: javax.faces.component.html.HtmlBody,Id: j_id_j][Class
Re: Unexpected behaviour of duplicate id check algorithm
Hi I think I found the problem. In UserTagHandler there is a missing call to fcc.endComponentUniqueIdSection(); . That means all custom facelet tags will have the problem, but it will only be found when you use nested combinations of custom facelet tags and c:forEach tags. I'll fix it under MYFACES-3944 regards, Leonardo Uribe 2014-11-24 14:41 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi The only change that could cause like that between 2.1.x and 2.2.x is: https://issues.apache.org/jira/browse/MYFACES-3811 Fix c:forEach behavior once for all The previous algorithm (in 2.1.x) caused problems when you try combinations of c:forEach and ui:include and other tags, so in that sense the new algorithm is more stable. The new algorithm is activated when c:forEach iterates over a Serializable collection, so one way to use the old algorithm from 2.1.x is use a non Serializable collection. The stack trace shows that you are doing something very unusual in you page. The id shouln'd be that long: j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_ 1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_ 0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_ 17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 It should be something that cause the id to be generated in that way, maybe a hidden exception or something inside the iterated components. I see that do the iteration by c:forEach should be surrounded by a try{...} finally{...} block to avoid that situation. I suggest you to check with a debugger how c:forEach is being called. I have created this issue: https://issues.apache.org/jira/browse/MYFACES-3944 - Calls to fcc.startComponentUniqueIdSection(...) and fcc.endComponentUniqueIdSection(...) should be surrounded in a try finally block To deal with this, but that small fix will not solve the real cause of the problem you have. regards, Leonardo Uribe 2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de: Hi, I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and getting strange exception now, stating, that smth. wrong with ids on the page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING parameter value. With javax.faces.PARTIAL_STATE_SAVING set to false: java.lang.IllegalStateException: Client-id : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1 is duplicated in the faces tree. Component : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0
Re: Unexpected behaviour of duplicate id check algorithm
Hi In 2.1.x the logic in UserTagHandler was a bit different, so the bug is only in 2.2.x branch. I suppose it will solve the problem. I have already committed the code on trunk. regards, Leonardo Uribe 2014-11-24 15:09 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi I think I found the problem. In UserTagHandler there is a missing call to fcc.endComponentUniqueIdSection(); . That means all custom facelet tags will have the problem, but it will only be found when you use nested combinations of custom facelet tags and c:forEach tags. I'll fix it under MYFACES-3944 regards, Leonardo Uribe 2014-11-24 14:41 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi The only change that could cause like that between 2.1.x and 2.2.x is: https://issues.apache.org/jira/browse/MYFACES-3811 Fix c:forEach behavior once for all The previous algorithm (in 2.1.x) caused problems when you try combinations of c:forEach and ui:include and other tags, so in that sense the new algorithm is more stable. The new algorithm is activated when c:forEach iterates over a Serializable collection, so one way to use the old algorithm from 2.1.x is use a non Serializable collection. The stack trace shows that you are doing something very unusual in you page. The id shouln'd be that long: j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_ 1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_ 0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_ 17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 It should be something that cause the id to be generated in that way, maybe a hidden exception or something inside the iterated components. I see that do the iteration by c:forEach should be surrounded by a try{...} finally{...} block to avoid that situation. I suggest you to check with a debugger how c:forEach is being called. I have created this issue: https://issues.apache.org/jira/browse/MYFACES-3944 - Calls to fcc.startComponentUniqueIdSection(...) and fcc.endComponentUniqueIdSection(...) should be surrounded in a try finally block To deal with this, but that small fix will not solve the real cause of the problem you have. regards, Leonardo Uribe 2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de: Hi, I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and getting strange exception now, stating, that smth. wrong with ids on the page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING parameter value. With javax.faces.PARTIAL_STATE_SAVING set to false: java.lang.IllegalStateException: Client-id : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1 is duplicated in the faces tree. Component : j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_
[ANNOUNCE] MyFaces Core v2.2.6 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.6. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.6 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.6 Bug [MYFACES-3920] - HtmlPanelGroup implements ClientBehaviorHolder, but does not render it's behaviors [MYFACES-3923] - MyFaces uses Servlet 3.0 only method cookie.setHttpOnly(true) [MYFACES-3927] - Myfaces 2.2.4 not compatible with Google App Engine [MYFACES-3928] - MyFaces doesn't resolve in OSGi environment when Servlet API 3.1 is present [MYFACES-3930] - java.lang.IllegalArgumentException: null at HtmlRenderKitImpl.createResponseWriter [MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet = NullPointerException [MYFACES-3934] - f:view transient=true does not work on when client side state saving is enabled and PSS is set to false [MYFACES-3935] - h:inputTextarea with null value throws NullPointerException [MYFACES-3936] - Flash object requires cleanup strategy when client window feature is used Improvement [MYFACES-3937] - Set default for org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION to 4 [MYFACES-3938] - Faces Flow requires cleanup strategy regards, Leonardo Uribe
Re: ViewScoped bean created multiple times?
Hi In my opinion, you should use @PostConstruct annotation over init method. But the code has an entry like this: @ManagedProperty(value=#{priceController}) private PriceController priceController; Since this is inside a view scope bean, PriceController instance is saved with the view scope bean. It is a pitfall of JSF managed beans, solved in CDI beans. My suggestions is don't use @ManagedProperty inside the view scope bean and instead use facesContext.getApplication().evaluateExpressionGet(...) to get your beans, so you can always have the right instance without include it into the state. The best strategy in my opinion is use request scope beans for encode behavior and view scope beans as data holders. regards Leonardo Uribe 2014-11-07 19:02 GMT-05:00 Thomas Andraschko andraschko.tho...@gmail.com: Constructor is called multiple times by design - thats how object serialization works. Serislization is enabled by default in myfaces to support clustering/failover. No clue about viewaction - i cant use jsf 2.2. Am Freitag, 7. November 2014 schrieb Bjørn T Johansen : 2.2, like this.: faces-config xmlns=http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd; version=2.2 No, javax.faces.PARTIAL_STATE_SAVING is set to true... BTJ On Fri, 7 Nov 2014 16:21:29 -0500 Kito Mann kito.m...@virtua.com javascript:; wrote: OK. What version do you have in your faces-config.xml file? Also, do you have javax.faces.PARTIAL_STATE_SAVING set to false in web.xml? ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http:// http://blogs.jsfcentral.com/JSFNewscast/enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Fri, Nov 7, 2014 at 4:09 PM, Bjørn T Johansen b...@havleik.no javascript:; wrote: No bindings... And using Myfaces 2.2.5 BTJ On Fri, 7 Nov 2014 15:57:00 -0500 Kito Mann kito.m...@virtua.com javascript:; wrote: Hello Bjorn, Do you have component bindings in your page (i.e h:myComponent binding=#{myBean.comp}/)? That causes the exact behavior you're describing in versions of JSF prior to 2.2. What version of MyFaces are you using? ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http:// http://blogs.jsfcentral.com/JSFNewscast/enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Fri, Nov 7, 2014 at 3:42 PM, Bjørn T Johansen b...@havleik.no javascript:; wrote: I trying to create a webapplication using request and/or viewscope instead of sessionscope, which I have always used... (Neved needed to concern myself with memory usage in the apps I have implemented.. :) ) But I now have a problem using @ViewScoped.. When I access index.xhtml which uses a managed bean in viewscope, the constructor is called multiple times. And the same with an init method, that should be called only once. I am using..: f:metadata f:viewAction action=#{calendarController.initPrices} / /f:metadata h:head.. to call the init method, but I have also tried using f:event prerenderView and also @PostConstruct but I am not able to make the bean call the init method only once... What am I missing? Regards, BTJ -- --- Bjørn T Johansen b...@havleik.no javascript:; --- Someone wrote: I understand that if you play a Windows CD backwards you hear strange Satanic messages To which someone replied: It's even worse than that; play it forwards and it installs Windows ---
Re: Understanding page lifecycle on return from a faces flow
Hi I think the problem happens because the navigation is executed on invoke application case, but by default f:viewAction is set to be executed on invoke application phase too. Probably f:viewAction is executed before the navigation. Faces Flow allows to set initializer and finalizer methods, so the best way could be do the check in a finalizer method. Or if you want, you can use f:event type=preRenderView listener=#{...}/, to execute a method after invoke application phase, but before render. regards, Leonardo Uribe 2014-10-21 10:51 GMT-05:00 Alexander Wise sa...@clickshare.com: Greetings, I am trying to use a viewAction as a mechanism to enforce pre-conditions on pages, and am using faces flows to present any interaction required to enforce the preconditions. For example, imagine a “one click” ordering scheme, where clicking on a link takes you to the confirmation page for the order, but before the order can proceed, we need to make sure the customer is logged in (presenting a login/signup flow if they aren’t), and that they have a current credit card on file (presenting an update billing information flow if they aren’t)... I am entering the flow with a viewAction: f:viewAction action=#{authenticator.enter} onPostback=true / Authenticator.enter checks the pre-condition on the page, and navigates to the login flow, if the user is not logged in. But, at the end of the flow, I want enter() to be invoked again in case their are other preconditions that need to be enforced. A phase listener shows all the same phases are being executed, but the viewAction is not getting triggered again, so clearly, I don’t understand the page lifecycle sufficiently… Can anybody explain why the viewAction doesn’t get triggered again, and what I can do to change that? /s
Re: Myfaces Core - OSGi Bundle expand version range
Hi The base code of MyFaces is in apache svn repo: 2.2.x http://svn.apache.org/repos/asf/myfaces/core/trunk/ 2.1.x http://svn.apache.org/repos/asf/myfaces/core/branches/2.1.x/ 2.0.x http://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/ The fix you need should be done in bundle/pom.xml. It is quite simple, so I have changed the issue to be solved for the next release. regards, Leonardo Uribe 2014-10-14 8:16 GMT-05:00 Achim Nierbeck bcanh...@googlemail.com: Hi, as working on different OSGi technologies I just came across the fact that the MyFaces Core bundle is not compatible in working with Servlet API 3.1, see also [1] I wanted to help on this so what's the best way of patching this. Looking at the github 2.1.x branch, the pom seems wrong to me (saying it's a 2.2.0-SNAPSHOT) [2]. So what's the best approach to actually file a quick patch for this? regards, Achim [1] - https://issues.apache.org/jira/browse/MYFACES-3928 [2] - https://github.com/apache/myfaces/blob/2.1.x/pom.xml -- Apache Member Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead blog http://notizblog.nierbeck.de/ Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS Software Architect / Project Manager / Scrum Master
[ANNOUNCE] MyFaces Core v2.0.22 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.22. MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.22 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.0.22 Bug [MYFACES-3848] - FunctionMapper not found when using a function inside value of f:setPropertyActionListener [MYFACES-3875] - Unhandled attribute for for custom converter [MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows [MYFACES-3887] - UIDebug is alwas rendered=true (no ValueExpression evaluation) [MYFACES-3890] - Component added using vdl.createComponent(...) is removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1 [MYFACES-3902] - jsf.js: error handling output improvement [MYFACES-3907] - NullPointerException in ManagedBeanBuilder after server restart [MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl [MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered [MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field [MYFACES-3921] - NullPointerException at SerializedViewCollection Improvement [MYFACES-3895] - Missed space character in ViewExpiredException getMessage() [MYFACES-3906] - jsf.js: evaled javascript errors are not handled the same way as other errors [MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list of removed client IDs stable over time regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.1.16 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.1.16. MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.1.16 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.1.16 Bug [MYFACES-3841] - h:inputTextArea removes leading newline [MYFACES-3848] - FunctionMapper not found when using a function inside value of f:setPropertyActionListener [MYFACES-3875] - Unhandled attribute for for custom converter [MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows [MYFACES-3887] - UIDebug is alwas rendered=true (no ValueExpression evaluation) [MYFACES-3888] - Resource from classpath locked on windows after change in eclipse [MYFACES-3890] - Component added using vdl.createComponent(...) is removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1 [MYFACES-3902] - jsf.js: error handling output improvement [MYFACES-3907] - NullPointerException in ManagedBeanBuilder after server restart [MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl [MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered [MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field [MYFACES-3921] - NullPointerException at SerializedViewCollection Improvement [MYFACES-3895] - Missed space character in ViewExpiredException getMessage() [MYFACES-3906] - jsf.js: evaled javascript errors are not handled the same way as other errors [MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list of removed client IDs stable over time regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.5 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.5. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.5 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.5 Bug [MYFACES-3891] - Don't write flash-scoped variables in ErrorPageWriter when FLASH_SCOPE_DISABLED=true [MYFACES-3907] - NullPointerException in ManagedBeanBuilder after server restart [MYFACES-3912] - Exception when loading FlowScopeBeanHolder [MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl [MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered [MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field [MYFACES-3920] - HtmlPanelGroup implements ClientBehaviorHolder, but does not render it's behaviors [MYFACES-3924] - Memory leak in ViewScopeBeanHolder Improvement [MYFACES-3895] - Missed space character in ViewExpiredException getMessage() [MYFACES-3906] - jsf.js: evaled javascript errors are not handled the same way as other errors [MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list of removed client IDs stable over time Wish [MYFACES-3789] - Change default refresh period for facelets from 2 to 0 sec (=always refresh) [MYFACES-3917] - Remove compile scope dependency - geronimo jcdi spec 1.0 from myfaces-api maven build regards, Leonardo Uribe
Re: NPE in DefaultFaceletFactory._createViewMetadataFacelet from MyFaces 2.2.4 and Karaf 3.0.1
Hi The line that throw the exception has this code: String alias = / + _removeFirst(url.getFile(), getBaseUrl().getFile()); the base url is (/), so probably it is resolved as null. This reference is taken through ResourceResolver, so a custom implementation could fix the issue. regards, Leonardo Uribe 2014-09-06 4:44 GMT-05:00 Paul Spencer pau...@apache.org: The log entries below are from MyFaces 2.1.15 and 2.2.4, so is this a regression bug? *** * MyFaces 2.1.15 *** 2014-09-06 05:16:40,601 | TRACE | qtp195585050-76 | FaceletViewDeclarationLanguage | 640 - org.apache.myfaces.core.impl - 2.1.15 | Initializing 2014-09-06 05:16:40,657 | DEBUG | qtp195585050-76 | FaceletViewDeclarationLanguage | 640 - org.apache.myfaces.core.impl - 2.1.15 | Successfully loaded library: bundle://632.0:1/META-INF/primefaces-p.taglib.xml 2014-09-06 05:16:40,660 | DEBUG | qtp195585050-76 | FaceletViewDeclarationLanguage | 640 - org.apache.myfaces.core.impl - 2.1.15 | Successfully loaded library: bundle://632.0:1/META-INF/primefaces-pm.taglib.xml 2014-09-06 05:16:40,663 | DEBUG | qtp195585050-76 | Resource | 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url from external context: null 2014-09-06 05:16:40,665 | DEBUG | qtp195585050-76 | DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl - 2.1.15 | Using ResourceResolver: DefaultResourceResolver 2014-09-06 05:16:40,665 | DEBUG | qtp195585050-76 | DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl - 2.1.15 | Using Refresh Period: -1 2014-09-06 05:16:40,666 | TRACE | qtp195585050-76 | FaceletViewDeclarationLanguage | 640 - org.apache.myfaces.core.impl - 2.1.15 | Initialization Successful 2014-09-06 05:16:40,668 | DEBUG | qtp195585050-76 | Resource | 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url from external context: bundle://636.3:0/helloWorld.xhtml 2014-09-06 05:16:40,670 | DEBUG | qtp195585050-76 | Resource | 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url from external context: bundle://636.3:0/helloWorld.xhtml 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76 | Resource | 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url from external context: bundle://636.3:0/helloWorld.xhtml 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76 | DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl - 2.1.15 | Creating Facelet used to create View Metadata for: bundle://636.3:0/helloWorld.xhtml 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76 | Compiler | 640 - org.apache.myfaces.core.impl - 2.1.15 | Initializing 2014-09-06 05:16:40,680 | DEBUG | qtp195585050-76 | Compiler | 640 - org.apache.myfaces.core.impl - 2.1.15 | Initialization Successful 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed : http://www.w3.org/1999/xhtml 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Starting Unit: org.apache.myfaces.view.facelets.compiler.NamespaceUnit@4b9284dc and adding it to parent: org.apache.myfaces.view.facelets.compiler.CompilationUnit@50ae47 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed f: http://java.sun.com/jsf/core 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed h: http://java.sun.com/jsf/html 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed ui: http://java.sun.com/jsf/facelets 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed p: http://primefaces.org/ui 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Tag Pushed: /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Starting Unit: /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view and adding it to parent: org.apache.myfaces.view.facelets.compiler.NamespaceUnit@4b9284dc 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Finished Unit: /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76 | CompilationManager | 640 - org.apache.myfaces.core.impl - 2.1.15 | Finished Unit: org.apache.myfaces.view.facelets.compiler.NamespaceUnit
Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException
Hi I have tested the latest snapshot from trunk and it is working with tomee 1.7.0. I don't see any exception from this side. regards, Leonardo Uribe 2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com: Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i want to use myfaces 2.2.4 because i want to use the @javax.faces.view.ViewScoped (i use the omnifaces viewscoped) and the f:viewAction. But again im getting javax.enterprise.inject.AmbiguousResolutionException: Ambiguous resolution exception that i reported a few months ago, apparently myfaces 2.2.4 is not working with ears in tomee 1.7.0. I already reported to tomee mailing list but @Romain sayed think so but more a MF issue this time I think @Leonardo 2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. smithh032...@gmail.com: if you are not able to use MyFaces 2.2 @ViewScoped, you may need to keep OmniFaces CDI @ViewScoped until someone helps you with your issue. Some months ago, I tested MyFaces 2.2 with OmniFaces CDI @ViewScoped; all of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I experienced no issues. My app is not packaged as an EAR. today, i am using MyFaces 2.2 @ViewScoped beans even though I still have OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped). For the first day, running MyFaces 2.2, I am quite pleased. No issues to report, no exceptions in tomee/tomcat log files. On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed CODI and my app is package as ear. maybe i need to try tomee 1.6.1-snapshot 2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces api and impl 2.2.0 that's exactly what I did and I don't get the error. Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too? -- --- *SCJA. José Luis Cetina* --- -- --- *José Luis Cetina* ---
Re: SERIALIZE_STATE_IN_SESSION - What does it do?
Hi Check if your view scope managed beans implements Serializable interface. When SERIALIZE_STATE_IN_SESSION, it forces serialization of all view scope beans, and if you have not marked them as Serializable, the values will get lost. In a cluster, it is possible to find configurations where a session is serialized and deserialized, so SERIALIZE_STATE_IN_SESSION help with that scenario, to avoid exceptions later when the session is deserialized. regards, Leonardo Uribe 2014-09-04 14:51 GMT-05:00 kim.cal...@oneamerica.com: We have a custom address tag that seems to behave differently based on whether SERIIALIZE_STATE_IN_SESSION is set to true or false. When it is set to true, the values entered by the user on the page never make it to the managed bean. When it is set to false, the values entered do make it to the managed bean. Any idea why changing the value of this parameter would impact the property being updated in the managed bean or not? Our applications are running in a clustered environment, so we are thinking that SERIALIZE_STATE_IN_SESSION should be set to true so things will failover correctly. Is that correct? Thanks This e-mail message is intended only for the use of the individual or entity to which the transmission is addressed. Any interception may be a violation of law. If you are not the intended recipient, any dissemination, distribution or copying of this e-mail is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the document.
Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException
As you already know, MyFaces provide some extensions and those extensions register some CDI beans. But the way how the dependencies are loaded are controlled by Tomee and by the CDI implementation, in this case OWB. I have tried in the past to avoid the CDI beans in the integration point, but it is not possible, you need one in order to hold the beans in the scope, and you cannot access JSF from CDI (it works the opposite, access CDI from JSF). regards, Leonardo Uribe 2014-09-04 15:25 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com: the issue is wars of an ear inherit from lib beans so mf shouldn't use it (can be done adding a bean with a generated name by webapp - and get the name from the servlet context for instance) on tomee side we can skip mf cdi beans in ear lib part if it can help Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-04 22:23 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: @Leonardo: with ears? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-04 22:12 GMT+02:00 Leonardo Uribe lu4...@gmail.com: Hi I have tested the latest snapshot from trunk and it is working with tomee 1.7.0. I don't see any exception from this side. regards, Leonardo Uribe 2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com: Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i want to use myfaces 2.2.4 because i want to use the @javax.faces.view.ViewScoped (i use the omnifaces viewscoped) and the f:viewAction. But again im getting javax.enterprise.inject.AmbiguousResolutionException: Ambiguous resolution exception that i reported a few months ago, apparently myfaces 2.2.4 is not working with ears in tomee 1.7.0. I already reported to tomee mailing list but @Romain sayed think so but more a MF issue this time I think @Leonardo 2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. smithh032...@gmail.com: if you are not able to use MyFaces 2.2 @ViewScoped, you may need to keep OmniFaces CDI @ViewScoped until someone helps you with your issue. Some months ago, I tested MyFaces 2.2 with OmniFaces CDI @ViewScoped; all of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I experienced no issues. My app is not packaged as an EAR. today, i am using MyFaces 2.2 @ViewScoped beans even though I still have OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped). For the first day, running MyFaces 2.2, I am quite pleased. No issues to report, no exceptions in tomee/tomcat log files. On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed CODI and my app is package as ear. maybe i need to try tomee 1.6.1-snapshot 2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces api and impl 2.2.0 that's exactly what I did and I don't get the error. Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too? -- --- *SCJA. José Luis Cetina* --- -- --- *José Luis Cetina* ---
Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException
2014-09-04 16:04 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com: but you can share in both something (common thing is the classloader) to match the bean (or name) you need. I don't understand. MyFaces just provide the extension points. When and how the extensions are called are up to CDI and maybe Tomee. I suppose the AmbiguousResolutionException is caused because MyFaces is loaded twice by Tomee (when it is using ear). Split that code in a separate jar will not help. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-04 22:38 GMT+02:00 Leonardo Uribe lu4...@gmail.com: As you already know, MyFaces provide some extensions and those extensions register some CDI beans. But the way how the dependencies are loaded are controlled by Tomee and by the CDI implementation, in this case OWB. I have tried in the past to avoid the CDI beans in the integration point, but it is not possible, you need one in order to hold the beans in the scope, and you cannot access JSF from CDI (it works the opposite, access CDI from JSF). regards, Leonardo Uribe 2014-09-04 15:25 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com: the issue is wars of an ear inherit from lib beans so mf shouldn't use it (can be done adding a bean with a generated name by webapp - and get the name from the servlet context for instance) on tomee side we can skip mf cdi beans in ear lib part if it can help Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-04 22:23 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com: @Leonardo: with ears? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-09-04 22:12 GMT+02:00 Leonardo Uribe lu4...@gmail.com: Hi I have tested the latest snapshot from trunk and it is working with tomee 1.7.0. I don't see any exception from this side. regards, Leonardo Uribe 2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com: Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i want to use myfaces 2.2.4 because i want to use the @javax.faces.view.ViewScoped (i use the omnifaces viewscoped) and the f:viewAction. But again im getting javax.enterprise.inject.AmbiguousResolutionException: Ambiguous resolution exception that i reported a few months ago, apparently myfaces 2.2.4 is not working with ears in tomee 1.7.0. I already reported to tomee mailing list but @Romain sayed think so but more a MF issue this time I think @Leonardo 2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. smithh032...@gmail.com: if you are not able to use MyFaces 2.2 @ViewScoped, you may need to keep OmniFaces CDI @ViewScoped until someone helps you with your issue. Some months ago, I tested MyFaces 2.2 with OmniFaces CDI @ViewScoped; all of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I experienced no issues. My app is not packaged as an EAR. today, i am using MyFaces 2.2 @ViewScoped beans even though I still have OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped). For the first day, running MyFaces 2.2, I am quite pleased. No issues to report, no exceptions in tomee/tomcat log files. On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed CODI and my app is package as ear. maybe i need to try tomee 1.6.1-snapshot 2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina maxtorz...@gmail.com wrote: I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces api and impl 2.2.0 that's exactly what I did and I don't get the error. Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too? -- --- *SCJA. José Luis Cetina* --- -- --- *José Luis Cetina* ---
Re: SERIALIZE_STATE_IN_SESSION - What does it do?
Hi 2014-09-04 16:23 GMT-05:00 kim.cal...@oneamerica.com: Leonardo, Thanks for the response. We don't have any view scoped managed beans. The bean is session scoped. It does implement Serializable. We recently migrated from MyFaces 1,1,4 to MyFaces 2.1.13. This worked fine before, but isn't working now, if SERIALIZE_STATE_IN_SESSION is set to true. We are still using JSPs, not Facelets. I've stepped through the code several times and haven't discovered the issue yet. Many things has happened since 1.1. JSP was deprecated in JSF 2.0 and the suggested way is migrate JSP views into Facelets. Some component libraries for JSF 2.0 deprecate JSP too. My suggestion is you could try first move your application to MyFaces 1.2.12 (JSF 1.2) (change from JSF 1.1 EL to Unified EL) and then convert your JSP views into Facelets and try 2.1.13. regards, Leonardo Uribe Kim Calvin Sr Systems Consultant - Web Solutions OneAmerica P.O. Box 368 Indianapolis, IN 46206 Phone: (317) 285-2401 Fax: (317) 285-7696 kim.cal...@oneamerica.com OneAmerica companies: AUL | State Life | OneAmerica Securities | McCready and Keene | PML | AUL RMS From: Leonardo Uribe lu4...@gmail.com To: MyFaces Discussion users@myfaces.apache.org, Date: 09/04/2014 04:19 PM Subject:Re: SERIALIZE_STATE_IN_SESSION - What does it do? Hi Check if your view scope managed beans implements Serializable interface. When SERIALIZE_STATE_IN_SESSION, it forces serialization of all view scope beans, and if you have not marked them as Serializable, the values will get lost. In a cluster, it is possible to find configurations where a session is serialized and deserialized, so SERIALIZE_STATE_IN_SESSION help with that scenario, to avoid exceptions later when the session is deserialized. regards, Leonardo Uribe 2014-09-04 14:51 GMT-05:00 kim.cal...@oneamerica.com: We have a custom address tag that seems to behave differently based on whether SERIIALIZE_STATE_IN_SESSION is set to true or false. When it is set to true, the values entered by the user on the page never make it to the managed bean. When it is set to false, the values entered do make it to the managed bean. Any idea why changing the value of this parameter would impact the property being updated in the managed bean or not? Our applications are running in a clustered environment, so we are thinking that SERIALIZE_STATE_IN_SESSION should be set to true so things will failover correctly. Is that correct? Thanks This e-mail message is intended only for the use of the individual or entity to which the transmission is addressed. Any interception may be a violation of law. If you are not the intended recipient, any dissemination, distribution or copying of this e-mail is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the document. __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ This e-mail message is intended only for the use of the individual or entity to which the transmission is addressed. Any interception may be a violation of law. If you are not the intended recipient, any dissemination, distribution or copying of this e-mail is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the document.
Re: features.xml for MyFaces v2.2.x?
Hi I think it doesn't exists, at least in the svn, but it is not hard to create one. regards, Leonardo Uribe 2014-09-03 9:29 GMT-05:00 Paul Spencer pau...@apache.org: I am looking for a features.xml to easily install the MyFaces bundle and its dependent bundles into Karaf. I looked in the MyFaces website, but only found the bundle. Does such a file exist? If so, where? Paul Spencer
Re: Performance issue with component bindings and Ajax requests
Hi I checked the algorithm and I have also fixed the problem (committed in 2.0.x, 2.1.x and 2.2.x). See: https://issues.apache.org/jira/browse/MYFACES-3918 I think the solution is ok, but an extra test could be also helpful. regards, Leonardo 2014-08-20 2:45 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 20/08/2014 09:41, Marc Heinz wrote: Thanks for the quick answer! We tried disabling PSS but this actually broke several other things, so we would prefer not to touch it right now. Setting the flag org.apache.myfaces.REMOVING_COMPONENTS_BUILD however seems to do the trick... (we though about using it before but we were unsure about the possible implications). I've created an issue as suggested: https://issues.apache.org/jira/browse/MYFACES-3918 I will report any possible regression we find there, and I will test again when a fix becomes available. I am also interesting by this issue and ready to test a fix in the days to come. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hi 2014-08-20 6:36 GMT-05:00 William Lucy wtl...@us.ibm.com: Hello all, We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen -, the following navigation does not work (the output link just triggers a refresh): f:view h:form h:commandLink id=link action=toLink.html h:outputText value=Link / /h:commandLink /h:form /f:view This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2 and with 2.2 it is the right time to do a cleanup in the codebase. The issue here seems to stem from the oamSubmit.js script; in that file there is a call myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId); which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have return formInfo.getFormName() + UINamingContainer.getSeparatorChar (FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME; which will cause the wrong hidden field name to be searched, and the broken actions seen here. Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR use? Thanks for any feedback! It is a bug. We should not use UINamingContainer.getSeparatorChar(...) to render that hidden field and enforce ':' instead. The reason is the intention of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css when you use the ':', but in this case the intention is to create a hidden field, with no real underlying component, so it is better to let ':' on the js file. Please create an issue in MyFaces issue tracker and I'll fix it on all affected branches. https://issues.apache.org/jira/browse/MYFACES regards, Leonardo Uribe Bill Lucy IBM RTP WebSphere wtl...@us.ibm.com
Re: Performance issue with component bindings and Ajax requests
Hi The problem is the call to formRoot.getChildren().clear() activates the listener for PreRemoveFromViewEvent and that one register the removed components. Since you are generating over and over components, after many requests that list becomes big. I can imagine two solutions: 1. Disable PSS on the affected views, using javax.faces.FULL_STATE_SAVING_VIEW_IDS param 2. Try to use this code on formRoot.getChildren().clear(); facesContext.getAttributes.put(org.apache.myfaces.REMOVING_COMPONENTS_BUILD, Boolean.TRUE); formRoot.getChildren().clear(); facesContext.getAttributes.remove(org.apache.myfaces.REMOVING_COMPONENTS_BUILD); That will avoid register the ids on the list, without side effects (that I can imagine right now, not 100% sure). Anyway, It is possible to find a solution changing the code in DefaultFaceletsStateManagementStrategy, so the list keeps stable over time, Please create an issue on MyFaces issue tracker: https://issues.apache.org/jira/browse/MYFACES regards, Leonardo Uribe 2014-08-19 8:12 GMT-05:00 Marc Heinz mhz4...@gmail.com: Hello everybody, We are currently encountering some performances issues with myfaces, and we would really appreciate some help on the subject. We are generating forms to be filled by the user dynamically (through component binding) from a set of externally managed rules. Here is a short overview: In our facelet: h:panelGroup id=formRoot binding=#{FormBean.formRoot}/ Our backing bean: @RequestScoped public class FormBean { private boolean rebuildDone = false; private UIPanel formRoot; public UIPanel getFormRoot() { if (!rebuildDone) { rebuildForm(); } return formRoot; } public void setFormRoot(UIPanel formRoot) { // Ignore. } // Public method to rebuild the current form content in reaction to updates fired from Ajax managed components. public void rebuildForm() { if (formRoot == null) { formRoot = new UIPanel(); // The whole component tree is marked as transient. formRoot.setTransient(true); formRoot.setId(formRoot); } // Clear the existing tree. formRoot.getChildren().clear(); // Start building the new component tree with formRoot as parent. [...] } } We use Ajax extensively: all updates events are processed with AjaxBehaviorsListeners (wired on onchange client events). When a change is processed (during the INVOKE_APPLICATION phase), the value is validated and the GUI is refreshed by calling the rebuildForm() method. The existing component tree will then be *cleared* by calling getChildren().clear() on the binding root component. It will be then rebuilt entirely (even though only a small subset of components are usually affected). This is clearly inefficient, but this is some legacy code that we don't want to disturb unless strictly required. What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk): on all forms (but especially on forms with all lot of components) every Ajax request takes more time to complete than the previous one as long as we stay on the same view. On a form with ~70 fields, the turnaround time (measured with the Net panel of Firebug) goes from ~250ms (first request) to more than 1 second after ~15 update. After some profiling done with VisualVM, we pinpointed the location of the latency to: org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(), accountable for 70% of the processing time. On further inspection, it appears that a data structure, the list of removed client IDs (clientIdsRemoved), is growing endlessly across each request. We are not too sure where the problem is right now... Should we build the component tree only once during the RESTORE_VIEW phase and then update it? (this seems hardly doable) Are we simply doing something in the wrong phase? Should I raise an issue on this? Any feedback would be most appreciated, Thanks, Marc
Re: dep error?
Hi Instead use provided, these dependencies are optional: !-- CDI 1.0 -- dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jcdi_1.0_spec/artifactId version1.0/version scopecompile/scope optionaltrue/optional /dependency !-- Injection -- dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-atinject_1.0_spec/artifactId version1.0/version scopecompile/scope optionaltrue/optional /dependency It is better to let it like that, because it is valid to use JSF 2.2 artifacts without CDI. regards, Leonardo Uribe 2014-08-04 16:00 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys just to mention 2.2.4 has: 40 [INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.4:compile 41 [INFO] | +- org.apache.geronimo.specs:geronimo-jcdi_1.0_spec:jar:1.0:compile 42 [INFO] | \- org.apache.geronimo.specs:geronimo-atinject_1.0_spec:jar:1.0:compile Wouldn't it be better to set geronimo deps as provided? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
Re: null Long values displayed as 0
Hi All files from org.apache.el comes from the EL library, so it is out of MyFaces scope. I think you cannot override the EL coercion rules, unless you change the underlying EL library. regards, Leonardo 2014-07-16 12:20 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 16/07/2014 19:15, titou10 titou10 wrote: Maybe you could try to add property org.apache.el.parser.COERCE_TO_ZERO=false to your JVM Denis/MTL No, COERCE_TO_ZERO is useful in the opposite way, when submitting the value. BTW, I already use it. Thx anyway. Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Getting NPE when flowscope value evaluates to null.
Hi I tried to set the null value with MyFaces 2.2.4 and it works as expected. But trying with Mojarra 2.2.7 I get this: javax.faces.component.UpdateModelException: java.lang.NullPointerException at javax.faces.component.UIInput.updateModel(UIInput.java:866) at javax.faces.component.UIInput.processUpdates(UIInput.java:749) at javax.faces.component.UIForm.processUpdates(UIForm.java:281) Caused by: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124) at javax.el.MapELResolver.setValue(MapELResolver.java:265) at com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:255) at com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:281) at com.sun.el.parser.AstValue.setValue(AstValue.java:201) at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:291) at org.apache.webbeans.el22.WrappedValueExpression.setValue(WrappedValueExpression.java:95) at com.sun.faces.facelets.el.TagValueExpression.setValue(TagValueExpression.java:131) at javax.faces.component.UIInput.updateModel(UIInput.java:832) ... 34 more Take a look your classpath, probably something is not right. regards, Leonardo 2014-07-03 23:08 GMT-05:00 Paul Spencer pau...@apache.org: MyFaces 2.2.3 2.2.4 jetty-maven-plugin:8.1.15.v20140411 Getting NPE when Flow Scope parameter evaluates to null. If no value is entered for firstName before “continue” on campaigns/campaigns.xhtml is clicked, the NPE below thrown. Otherwise the page2.xhtml is displayed as expected. *** * campaigns/campaigns.xhtml *** h:outputLabel for=firstName value=First Name / h:inputText id=firstName value=#{flowScope.firstName} maxlength=10 / h:commandButton value=“Continue” action=“page2” / *** * campaigns/page2.xhtml *** h:commandButton value=“Exit action=campaigns-return / h:outputLabel for=firstName value=First Name / h:inputText id=“firstName value=#{flowScope.firstName} maxlength=10 / *** * Error displayed when page2.xhtml is returned and firstName is null *** java.lang.NullPointerException viewId=/campaigns/campaigns.xhtml location=/Users/paul/Documents/workspace-4.3.2/VenderRollsImporterMockUp/src/main/webapp/campaigns/campaigns.xhtml phaseId=UPDATE_MODEL_VALUES(4) Caused by: java.lang.NullPointerException - java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124) HtmlInputText class=class javax.faces.component.html.HtmlInputText” clientId=j_id_s:firstName disabled=false id=firstName immediate=false inView=true localValueSet=true maxlength=10 readonly=false rendered=true required=false size=-2147483648 transient=false valid=false value=#{flowScope.firstName} location=/campaigns/campaigns.xhtml at line 76 and column 82/ - State size:246 bytes *** * Scopes Value *** Request Parameters Name Value j_id_s:firstName j_id_s:j_id_x Continue j_id_s_SUBMIT 1 jfwid -lbh0f813a Is this normal? Paul Spencer
[ANNOUNCE] MyFaces Core v2.2.4 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.4. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.4 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.4 Bug [MYFACES-3841] - h:inputTextArea removes leading newline [MYFACES-3848] - FunctionMapper not found when using a function inside value of f:setPropertyActionListener [MYFACES-3879] - Passthrough attributes for f:selectItem and f:selectItems should be rendered by associated components [MYFACES-3886] - SerializedViewCollection does not update it's _keys list when _serializedViews contains key [MYFACES-3887] - UIDebug is alwas rendered=true (no ValueExpression evaluation) [MYFACES-3888] - Resource from classpath locked on windows after change in eclipse [MYFACES-3890] - Component added using vdl.createComponent(...) is removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1 [MYFACES-3893] - NullPointerException in ErrorPageWriter._writeAttributes [Line 1304] [MYFACES-3902] - jsf.js: error handling output improvement Improvement [MYFACES-3639] - The flash scope cookie is not HttpOnly New Feature [MYFACES-3880] - Allow view state to be rendered in the beginning of the form regards, Leonardo Uribe
Re: Content of ui:define variable not appearing in ui:include include fragment.
Hi Use ui:decorate instead ui:include in the parts you need an ui:define to be taken into account when the templates are resolved. regards, Leonardo Uribe 2014-07-01 9:29 GMT-05:00 Paul Spencer p...@intekon.com: Using MyFaces 2.2.3 The intent is for the contents of the ui:define variable page_title to appear both in the browser title bar and in the page’s content header area while using a common template across many pages. The content header area is displayed in the body of the page and is there to give each page a consistent look. In the example below, “My Page1 Title” appears as the title of the page1.jsp, but not in the header content of the page. Why does the ui:define variable page_title evaluate to blank/null in includes pages? Is there a better way to accomplish the intended behavior? *** * Page1.xhtml *** ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; h:body ui:composition template=/template/commonLayout.xhtml ui:define name=“page_title”My Page1 Title/ui:define ui:define name=“content f:view transient=“true” h1Page 1/h1 /f:view /ui:define /ui:composition /h:body /html *** * commonLayout.xhtml *** ?xml version=1.0 encoding=UTF-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; h:head meta http-equiv=Content-Type content=text/html; charset=UTF-8 / h:outputStylesheet library=css name=default.css / h:outputStylesheet library=css name=cssLayout.css / titleui:insert name=page_title //title /h:head h:body ui:debug / div id=page div id=top ui:insert name=header ui:include src=/template/commonHeader.xhtml/ /ui:insert /div div div id=left ui:insert name=menu ui:include src=/template/commonMenuLeft.xhtml / /ui:insert /div div id=content ui:insert name=content ui:include src=/template/commonContent.xhtml/ /ui:insert /div ui:debug/ui:debug /div div id=bottom ui:insert name=footer ui:include src=/template/commonFooter.xhtml / /ui:insert /div /div /h:body /html *** * commonHeader.xhtml *** ?xml version=1.0 encoding=UTF-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; body ui:component h1 style=text-align: center; color: black; background-color: white; ui:insert name=page_title / /h1 /ui:component /body /html Paul Spencer
Re: caption facet not document in h:datatable.
Hi It looks like UIData has getHeader()/getFooter(), but there is not getCaption(), so there is no @JSFFacet. Yes, you can create an issue as with priority trivial in: https://issues.apache.org/jira/browse/MYFACES regards, Leonardo 2014-06-30 8:49 GMT-05:00 Paul Spencer pau...@apache.org: The caption facet is not document for the tag h:datatable. http://myfaces.apache.org/core22/myfaces-impl/tagdoc/h_dataTable.html Should I create an issue for this? Paul Spencer
[ANNOUNCE] MyFaces Test v1.0.7 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Test 1.0.7. The Myfaces Test Framework provides mock object libraries, plus base classes for creating your own JUnit TestCases for JSF. For more information please see: http://myfaces.apache.org/test MyFaces Core is available in the central Maven repository under Group ID org.apache.myfaces.test. Release Notes - MyFaces Test - Version 1.0.7 Improvement [MYFACESTEST-70] - customizable ClassLoader regards, Leonardo Uribe
Re: NPE when view pooling / CACHE_EL_EXPRESSIONS == alwaysRecompile
Hi I have checked the problem in deep and I was not able to reproduce the problem. The reason is view pooling algorithm saves UIViewRoot state fully (markInitialState is set to false, and the state is used later to clone the views), and that also includes the binding table for tags, so this table should be always saved and restored correctly. Really it is not a problem if you set EL cache mode to strict, because if you are using view pool in that view, enable or disable EL cache will have minimal effect. It should be some additional not seen element that is making it fail, or in other words, it should be a combination between different things, but it is impossible to understand it without an example. regards, Leonardo 2014-06-12 3:38 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi An example to reproduce it could help in this case. Leonardo. On Jun 10, 2014 11:21 PM, l.pe...@senat.fr l.pe...@senat.fr wrote: (republished here following the advice of Gerhard Petracek on us...@deltaspike.apache.org) Dear all, I have the following NPE when view pooling is activated and CACHE_EL_EXPRESSIONS is set to alwaysRecompile : java.lang.NullPointerException at org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:107) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68) at org.apache.el.parser.AstValue.getValue(AstValue.java:161) at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:47) at org.apache.el.parser.AstNot.getValue(AstNot.java:44) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185) at org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96) at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:377) at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1211) at javax.faces.component.UIComponentBase._isPhaseExecutable(UIComponentBase.java:2440) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1386) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIForm.processDecodes(UIForm.java:154) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIViewRoot._processDecodesDefault(UIViewRoot.java:1687) at javax.faces.component.UIViewRoot.access$500(UIViewRoot.java:77) at javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcessor.process(UIViewRoot.java:1778) at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1653) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:869) at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:42) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143) at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:46) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.HibernateNoCacheFilter.doFilter(HibernateNoCacheFilter.java:123) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.HibernateSessionConversationFilter.doFilter(HibernateSessionConversationFilter.java:128) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.HibernateUserFromPrincipalFilter.doFilter(HibernateUserFromPrincipalFilter.java:43) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.SessionCreationTrackingFilter.doFilter(SessionCreationTrackingFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243
Re: fileUpload native and with primefaces5 and with tomer
Hi It was fixed in 2.2.2, please use 2.2.3 instead. See: https://issues.apache.org/jira/browse/MYFACES-3865 regards, Leonardo 2014-06-17 7:51 GMT-05:00 maurojava mauro2java2...@gmail.com: I have tried to use primefaces5 fileUpload with configuratoins of native use of Part (no with commons ) into myfaces 2.2 . But not success. You know if the FacesServlet is annotated with @Multipart or i have configure with multipart into web.xml ? Please help me. I would als use myfaces2.2 into tomee 1.6 with substitution jars of myfaces api and myfaces ikplbtnto tomee/lib. Also into that case i have to confgure into web.xml the faces servlet with multpart config for use native Part with fileUplad of myfaces and for use fileUpload of primefaces5 with myfaces 2.2 and tomee ? -- View this message in context: http://myfaces.10567.n7.nabble.com/fileUpload-native-and-with-primefaces5-and-with-tomer-tp118244.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: NPE when view pooling / CACHE_EL_EXPRESSIONS == alwaysRecompile
Hi An example to reproduce it could help in this case. Leonardo. On Jun 10, 2014 11:21 PM, l.pe...@senat.fr l.pe...@senat.fr wrote: (republished here following the advice of Gerhard Petracek on us...@deltaspike.apache.org) Dear all, I have the following NPE when view pooling is activated and CACHE_EL_EXPRESSIONS is set to alwaysRecompile : java.lang.NullPointerException at org.apache.myfaces.view.facelets.el. FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:107) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68) at org.apache.el.parser.AstValue.getValue(AstValue.java:161) at org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:47) at org.apache.el.parser.AstNot.getValue(AstNot.java:44) at org.apache.el. ValueExpressionImpl.getValue(ValueExpressionImpl.java:185) at org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression .getValue(ContextAwareTagValueExpression.java:96) at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:377) at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1211) at javax.faces.component.UIComponentBase._isPhaseExecutable(UIComponentBase.java:2440) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1386) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIForm.processDecodes(UIForm.java:154) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401) at javax.faces.component.UIViewRoot._processDecodesDefault(UIViewRoot.java:1687) at javax.faces.component.UIViewRoot.access$500(UIViewRoot.java:77) at javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcess or.process(UIViewRoot.java:1778) at javax.faces.component. UIViewRoot._process(UIViewRoot.java:1653) at javax.faces.component. UIViewRoot.processDecodes(UIViewRoot.java:869) at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute( ApplyRequestValuesExecutor.java:42) at org.apache.myfaces.lifecycle. LifecycleImpl.executePhase(LifecycleImpl.java:196) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143) at org.apache.deltaspike.jsf.impl.listener.request. DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:46) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:305) at org.apache.catalina.core. ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.HibernateNoCacheFilter.doFilter( HibernateNoCacheFilter.java:123) at org.apache.catalina.core. ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:210) at fr.senat.faces.filters. HibernateSessionConversationFilter.doFilter(HibernateSessionConversationFilter.java:128) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:243) at org.apache.catalina.core. ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at fr.senat.faces.filters.HibernateUserFromPrincipalFilter.doFilter( HibernateUserFromPrincipalFilter.java:43) at org.apache.catalina.core. ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:210) at fr.senat.faces.filters. SessionCreationTrackingFilter.doFilter(SessionCreationTrackingFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:243) at org.apache.catalina.core. ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at
RE: Declaring a node that is not type 'view' as the start node.
Hi It looks like if register bean was in the flow scope associated with the flow to evaluate. The lookup will fail, because when the start node outcome is calculated, you have not entered the flow yet. The algorithm works in 2 steps: calculate the final outcome and then perform the transitions. I don't see any problem, because it is expected to fail in that scenario. Leonardo On Jun 10, 2014 1:01 PM, Mark m...@piggybankrupt.co.uk wrote: Hi, Can anyone confirm if this is a problem with the myfaces implementation? Regards, Mark. -Original Message- From: Mark [mailto:m...@piggybankrupt.co.uk] Sent: 19 May 2014 22:22 To: users@myfaces.apache.org Subject: Declaring a node that is not type 'view' as the start node. Declaring a node that is not type 'view' as the start node. Upon using flows within myfaces I can successfully enter and move within the flow provided the start node is a 'view' type. However, upon using a 'method-call' type or a 'switch' type I receive the errors below. My intention is to use a method-type node as a start-node to determine the first page in the flow, which is returned as an outcome. I found https://java.net/jira/browse/JAVASERVERFACES-3110, which presents the same problem in jsf. ##using method-call## java.lang.NullPointerException viewId=/index.xhtml location=C:\Users\Mark\Documents\Dev\login\ui\target\login-1.0-SNAPSHOT\inde x.xhtml phaseId=INVOKE_APPLICATION(5) Caused by: java.lang.NullPointerException at javax.faces.application.NavigationCaseWrapper.isRedirect(NavigationCaseWrapp er.java:111) HtmlCommandButton action=registration actionExpression=registration class=class javax.faces.component.html.HtmlCommandButton clientId=j_id_f:j_id_n disabled=false id=j_id_n immediate=false inView=true readonly=false rendered=true transient=false type=submit value=submit location=/index.xhtml at line 26 and column 71/ - State size:0 bytes ##using switch## WebBeans context with scope type annotation @FlowScoped does not exist within current thread viewId=/index.xhtml location=C:\Users\Mark\Documents\Dev\login\ui\target\login-1.0-SNAPSHOT\inde x.xhtml phaseId=INVOKE_APPLICATION(5) Caused by: javax.enterprise.context.ContextNotActiveException - WebBeans context with scope type annotation @FlowScoped does not exist within current thread at org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.jav a:299)HtmlCommandButton action=registration actionExpression=registration class=class javax.faces.component.html.HtmlCommandButton clientId=j_id_f:j_id_n disabled=false id=j_id_n immediate=false inView=true readonly=false rendered=true transient=false type=submit value=submit location=/index.xhtml at line 26 and column 71/ - State size:0 bytes ##setup -flow.xml## faces-config version=2.2 xmlns=http://xmlns.jcp.org/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd; flow-definition id=registration start-nodestartIt/start-node !--switch id=startIt case if#{register.startPage()==register}/if from-outcomeregister/from-outcome /case case/case default-outcomewelcomePage/default-outcome /switch-- method-call method id=startIt#{register.startPage()}/method default-outcomeregister/default-outcome /method-call view id=register vdl-document/registration/welcome.xhtml/vdl-document /view view id=welcomePage vdl-document/registration/registration1.xhtml/vdl-document /view flow-return id=return-index from-outcome/index.xhtml/from-outcome /flow-return /flow-definition /faces-config ##environment## Tommee+ 1.6 myfaces-api-2.2.2 myfaces-impl-2.2.2 replacing the tomee shipped 2.1.3 Any ideas? Regards, Mark Davis This email and any associated file contains confidential information and is intended solely for the person(s) named. If you are not the intended recipient, please do not read, print, store, disclose, re-distribute or act upon any information contained. Instead, please return to the sender and delete the message and / or files from your PC.
Re: Tag component instantiation and EL strict or alwaysRecompile modes
Hi Ludovic Good to know that. In my understanding, that code is the best option so far, and a lot of effort has been done to make it work. It was really hard to get it done. It has some good junit tests in place. Anyway we need to convince to the EG that myfaces behavior is the way to go. I think there is an issue already created on the spec, but I can't remember which number is. Regards Leonardo On Jun 10, 2014 10:55 AM, l.pe...@senat.fr l.pe...@senat.fr wrote: On 05/06/2014 07:27, Leonardo Uribe wrote: Hi Use the standard vdl.createComponent(...) included since JSF 2.2. It has the necessary code to do the trick properly. Please note in Myfaces this method has been extend to support facelet tags too. It should work with the view pool. Thank you Leonardo. I updated my code to use this method and it perfectly works. I could remove those naughty introspections, and that is always a long term bless. Best regards, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Submit form after disabling an input element via javascript?
Hi This is something complicated. If you disable a link on the server, you don't want a javascript that enable it on the client side, submit it and then found that something that you don't expect has happended on the server, right?. Who manage disable attribute? The client or the server? If an action is performed on the server, the server manage the attribute, so an Ajax request is mandatory to enable the input. Otherwise it could be a security hole. The thing to remember here is never trust on the client. No matter how intelligent we want the client to be, in cases like this one the state on the server is the king, and that will not change (because we can't!). Regards, Leonardo On Jun 10, 2014 10:06 PM, Karl Kildén karl.kil...@gmail.com wrote: Howard, thanks for the links and interest. In my case I already rewrote all my pages but I still think that error message is wrong. This is our use case: [X] Use Defaults for everything Once the user unclicks that checkbox 5 inputs are editable otherwise they get default. Since they get default I obviously just want JSF to leave me alone and you know behave like they are disabled ;) That way String fileName =newFile.txt; will not be changed and everything is smooth. What I see others complain about is that they have updated the value and then disabled yet still want it posted. This is a fundamental misunderstanding of how disabled works and differs from my scenario. In my case there was no reason to do it with javascript though and I did not like the solution in place so I fixed it by using f:ajax and disabled=#{condition} but had it been a central part of my system I would have been more hesitant to use the server side for such a simple operation. On 10 June 2014 21:51, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Leonardo, what are your thoughts on this thread? thanks. On Wed, Jun 4, 2014 at 11:43 AM, Karl Kildén karl.kil...@gmail.com wrote: Howard, To do that one would need a purpose. I fail to see the benefit other than bending the knee to a JSF limitation. On 4 June 2014 16:48, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Karl, if Javascript was written to enable field, why is there not Javascript to disable before submit? On Jun 4, 2014 8:33 AM, Karl Kildén karl.kil...@gmail.com wrote: Hi, my app recently upgraded from JSF 1.2 had a broken page with this in the log: WARNING: There should always be a submitted value for an input if it is rendered, its form is submitted, and it was not originally rendered disabled or read-only. You cannot submit a form after disab ling an input element via javascript. Consider setting read-only to true instead or resetting the disabled value back to false prior to form submission. Component : {Component-Path : [Class: javax.fa ces.component.UIViewRoot,ViewId: /pages/main.xhtml][Class: javax.faces.component.html.HtmlBody,Id: j_id_10][Class: javax.faces.component.html.HtmlForm,Id: f][Class: javax.faces.component.html.HtmlPane lGroup,Id: body][Class: javax.faces.component.html.HtmlPanelGroup,Id: contentBody][Class: javax.faces.component.html.HtmlPanelGrid,Id: j_id_2b_p][Class: javax.faces.component.html.HtmlInputText,Id: im portName] Location: /WEB-INF/facelets/admin/profileUploadForm.xhtml at line 88 and column 73} I don't understand this limitation. Is there some global flag I could use to make sure not included inputs are seen as unchanged or something? cheers
Re: Tag component instantiation and EL strict or alwaysRecompile modes
Hi Use the standard vdl.createComponent(...) included since JSF 2.2. It has the necessary code to do the trick properly. Please note in Myfaces this method has been extend to support facelet tags too. It should work with the view pool. regards Leonardo Uribe On Jun 4, 2014 12:37 PM, l.pe...@senat.fr l.pe...@senat.fr wrote: Dear all, I am doing something dirty in my code. I dynamically instantiate and add tag components to my component tree, according to some information that I have at runtime. My instantiation method looks like : public static UIComponent instantiateTagComponent(Location loc, String namespace, String localPrefix, String componentName, TagComponentParam params[]) { final String ERROR_MESSAGE = Erreur lors de l'instanciation d'un tag component; FacesContext ctx = FacesContext.getCurrentInstance(); AbstractFaceletContext fctx = (AbstractFaceletContext) ctx.getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY); fctx.pushPageContext(new PageContextImpl()); FaceletViewDeclarationLanguage vdl = new FaceletViewDeclarationLanguage(ctx); UIPanel panel = (UIPanel) ctx.getApplication().createComponent( UIPanel.COMPONENT_TYPE ); try { Method createCompiler = FaceletViewDeclarationLanguage .class.getDeclaredMethod(createCompiler,FacesContext.class); Method createFaceletFactory = FaceletViewDeclarationLanguage .class.getDeclaredMethod(createFaceletFactory, FacesContext.class,org.apache.myfaces.view.facelets. compiler.Compiler.class); createCompiler.setAccessible(true); createFaceletFactory.setAccessible(true); org.apache.myfaces.view.facelets.compiler.Compiler compiler = (org.apache.myfaces.view.facelets.compiler.Compiler) createCompiler.invoke(vdl, ctx); FaceletFactory ff = (FaceletFactory) createFaceletFactory.invoke(vdl, ctx, compiler); TagLibrary tl = compiler.createTagLibrary(); TagConfig tc = new JSFUtilsTagUnit(tl, namespace, localPrefix, componentName,params,loc); TagHandler th = tl.createTagHandler(namespace, componentName, tc); Field declaredField = FaceletCompositionContext. class.getDeclaredField(FACELET_COMPOSITION_CONTEXT_KEY); declaredField.setAccessible(true); FaceletCompositionContextImpl faceletCompositionContextImpl = new FaceletCompositionContextImpl(ff,ctx); Class? dfcClass = Class.forName(org.apache. myfaces.view.facelets.impl.DefaultFaceletContext); Field fMCTX = dfcClass.getDeclaredField(_mctx); fMCTX.setAccessible(true); fMCTX.set(fctx, faceletCompositionContextImpl); FacesContext.getCurrentInstance().getAttributes().put((String) declaredField.get(null),faceletCompositionContextImpl); FaceletCompositionContext mctx = (FaceletCompositionContext) FaceletCompositionContext.getCurrentInstance(fctx); mctx.startComponentUniqueIdSection(); th.apply( fctx, panel ); } catch (IOException ex) { log.error(ERROR_MESSAGE, ex); } catch (InvocationTargetException ex) { log.error(ERROR_MESSAGE, ex); } catch (NoSuchMethodException ex) { log.error(ERROR_MESSAGE, ex); } catch (NoSuchFieldException ex) { log.error(ERROR_MESSAGE, ex); } catch (SecurityException ex) { log.error(ERROR_MESSAGE, ex); } catch (ClassNotFoundException ex) { log.error(ERROR_MESSAGE, ex); } catch (IllegalArgumentException ex) { log.error(ERROR_MESSAGE, ex); } catch (IllegalAccessException ex) { log.error(ERROR_MESSAGE, ex); } finally { fctx.popPageContext(); } return panel; } This is dirty, but this perfectly works for quite some time now, at least until I stick to context-param param-nameorg.apache.myfaces.CACHE_EL_EXPRESSIONS/param-name param-valuestrict/param-value /context-param if I change it to alwaysRecompile, the state is not properly restored and I end with and NPE like : 04/06/2014 12:29:41 ERROR [http-bio-8443-exec-56] - Exception occur! java.lang.NullPointerException at org.apache.myfaces.view.facelets.el.FaceletStateValueExpression. getValue(FaceletStateValueExpression.java:107) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68) at org.apache.el.ValueExpressionImpl.getValue( ValueExpressionImpl.java:185) at org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression .getValue(ContextAwareTagValueExpression.java:96) at javax.faces.component._DeltaStateHelper.eval(_ DeltaStateHelper.java:360) at javax.faces.component.UIParameter.getValue(UIParameter.java:85) at org.apache.myfaces.shared.renderkit.html.HtmlLinkRendererBase. addChildParametersToHref
Re: Submit problem
Hi You should check if the html output is correct. Probably it could be a conflict between Tobago and the default JSF renderers, after all RenderKitWrapper was added in JSF 2.0. Even if you set renderKitId=”HTML_BASIC”, probably Tobago renderkit is still on top. regards, Leonardo Uribe 2014-05-08 10:42 GMT+02:00 Anton Sysoev bogatyr-h...@yandex.ru: Hi. I have a project based on Tobago 2.0 alpha 3 + Tomcat 7.0.34 + MyFaces Core 2.1.14 and it works fine. Now I need one page based on core jsf components only. I try to add a page like below in the project f:view xmlns=http://www.w3.org/1999/xhtml;http://www.w3.org/1999/xhtml xmlns:h=http://java.sun.com/jsf/html;http://java.sun.com/jsf/html xmlns:f=http://java.sun.com/jsf/core; renderKitId=”HTML_BASIC” html h[image: Дразнюсь]ody h:form h:inputText value=”#{mybean.number}”/ h:commandButton value=”submit” action=”#{mybean.store}”/ h:form /h[image: Дразнюсь]ody html /f:view Page is rendered but values are not submitted. Is this a bug or I’m doing something wrong? Thanks.
[ANNOUNCE] MyFaces Core v2.2.3 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.3. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.3 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.3 Bug [MYFACES-3874] - Component property class is not writable [MYFACES-3875] - Unhandled attribute for for custom converter [MYFACES-3876] - Clarify requeriments and behavior of HTML friendly markup feature [MYFACES-3877] - Add @ListenerFor(systemEventClass = PostRestoreStateEvent.class) causes StackOverflowException on MyFaces 2.2 [MYFACES-3878] - Update existing wrappers against new features in JSF 2.2 (ViewHandlerWrapper, ...) [MYFACES-3879] - Passthrough attributes for f:selectItem and f:selectItems should be rendered by associated components [MYFACES-3882] - Page with template and stylesheet not rendered correctly [MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows Task [MYFACES-3884] - Add missing impl/src/test/resources/org/apache/myfaces/view/facelets/**/testComposite/*.xhtml licenses [MYFACES-3885] - Add missing licenses to trivial js and xml files and exclude spi files in pom to clean up rat output regards, Leonardo Uribe
Re: Start MyFaces on demand?
Hi Don't worry about resource consumption. It is not a necessary. The code only loads the necessary classes and its memory footprint is minimal. Instead, you can reduce the size of some caches, usually affected by web config parameters. The effect will be minimal in any case. Leonardo On Apr 17, 2014 9:09 PM, Felipe Jaekel fkjae...@gmail.com wrote: I'm working in a JAX-RS project, it has a configuration page in JSP that I would like to change to JSF. As this page is rarely used, basically only when the project is first deployed, I'd like to be able to start MyFaces only when this paged is accessed to avoid unnecessary server resources consumption. I tried to remove the the load-on-startup parameter from the FacesServlet, but I keep seeing MyFaces output on the server startup. Is it possible to do or I don't have to worry about resources consumption in this case? Thanks
Re: ViewExpiredException, but session hasn't timed out
Hi I see, now I get it. By default MyFaces always renders the view state field at the form end. To solve your problem, you need to render it at the beginning of the form. JSF spec javadoc for h:form says this: ... Call ViewHandler.writeState() before the the close of the form element. Render all the necessary hidden fields for all commandLink instances in the page just before the close of the form element. ... What happen if we call it at the beginning of the form? there is a buffer that takes the response to inject the view state token before the end of the request, so you'll get an small increase of memory usage if you are using client side state saving, but besides that nothing else. This is an improvement/new feature, not a bug, so please create an issue in MyFaces issue tracker as improvement. regards, Leonardo 2014-04-10 14:05 GMT+02:00 Felipe Jaekel fkjae...@gmail.com: It's necessary to have a slow internet connection to reproduce this, so I can't test locally. While the page is loading the user hits a command button. As the page is still loading, I guess the view state is not created yet, so viewHandler.restoreView(facesContext, viewId) returns null. Thanks for the suggestion. I'll give it try, but according to the component documentation, using it for this case feels more like a workaround than a solution, so I'd like to see if there are more options. 2014-04-09 14:48 GMT-03:00 Howard W. Smith, Jr. smithh032...@gmail.com: Wow, you're using Shiro. Would be nice to have a list of steps how you duplicate this in your app, definitely and always. I definitely suggest you use OmniFaces restore view component to avoid this exception. On Apr 9, 2014 1:41 PM, Felipe Jaekel fkjae...@gmail.com wrote: I'm getting view expired exceptions if the user tries to perform an action in a page that isn't fully loaded. javax.faces.application.ViewExpiredException: /page/plano/plano.jsfNo saved view state could be found for the view identifier: /page/plano/plano.jsf at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:181) Looking at RestoreViewExceutor source code we have this: if (facesContext.getResponseComplete()) { // If the view handler cannot restore the view and the response // is complete, it can be an error or some logic in restoreView. return true; } else { // If the return from ViewHandler.restoreView() is null, throw a ViewExpiredException with an // appropriate error message. throw new ViewExpiredException(No saved view state could be found for the view identifier: + viewId, viewId); } } Page hasn't fully loaded yet, so facesContext.getResponseComplete() is returning false, but isn't there a way to avoid this? Page gets unusable after the VEE is thrown. Thanks in advance, Phillip Full stackTrace: javax.faces.application.ViewExpiredException: /page/plano/plano.jsfNo saved view state could be found for the view identifier: /page/plano/plano.jsf at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:181) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:98) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61) at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108) at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125) at
Re: DefaultContextAwareELException serialization problem
Hi An exception shouldn't be serializable. I can't find any line of code in MyFaces that serialize and exception, so I suppose you are doing it manually somehow. regards, Leonardo 2014-04-04 15:43 GMT+02:00 Felipe Jaekel fkjae...@gmail.com: I'm eventually seeing this in my Tomcat 7 logs: *IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.myfaces.view.facelets.el.DefaultContextAwareELException.* I'm using MyFaces 2.2.2. Shouldn't DefaultContextAwareELException be serializable? Thanks *Full stackTrace:* Abr 04, 2014 10:35:50 AM org.apache.catalina.session.StandardManager doLoad Grave: IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.myfaces.view.facelets.el.DefaultContextAwareELException java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.myfaces.view.facelets.el.DefaultContextAwareELException at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1354) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1595) at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:1060) at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:282) at org.apache.catalina.session.StandardManager.load(StandardManager.java:202) at org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:489) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5476) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3988) at org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:425) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1345) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519) at java.lang.Thread.run(Thread.java:744) Caused by: java.io.NotSerializableException: org.apache.myfaces.view.facelets.el.DefaultContextAwareELException at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1671) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:1077) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:430) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:351) at org.apache.catalina.session.StandardManager.stopInternal(StandardManager.java:516) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5655) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3981) ... 7 more Abr 04, 2014 10:35:50 AM org.apache.catalina.session.StandardManager startInternal Grave: Exception loading sessions from persistent storage
[ANNOUNCE] MyFaces Core v2.2.2 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.2. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.2 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.2 Bug [MYFACES-3865] - enctype=multipart/form-data not working [MYFACES-3866] - Unexpected result when using http://xmlns.jcp.org/jsf; namespace [MYFACES-3867] - SectionUniqueIdCounter.startUniqueIdSection(String base) does not generate prefix correctly [MYFACES-3869] - Ids used by c:if, c:forEach and other facelet tags requires to be unique per facelet [MYFACES-3870] - Attribute jsf:element elementName=... is not working as expected regards, Leonardo Uribe
Re: 2.2 stability
Hi @Karl I think your problem should be something different. I closed MYFACES-3869, since we have positive confirmation that the fix done works, but we need to analyze your problem and check if there is an error in MyFaces or not. We need more information than just the stack trace. MyFaces default error page gives the component tree using ErrorWriter and indicate which component has the duplicate id. There are some tricks involving programmatic component manipulation that can trigger a duplicate id exception, but not because they are correct and myfaces has a bug but because they are just invalid. In JSF 2.2, with vdl.createComponent it is possible to create programmatically added components using facelets in the right way. It is useful to use ui:debug tag to see the component tree and describe the steps involved in the exception, to help us to understand what could possible happen and how to fix it. regards, Leonardo Uribe 2014-03-13 7:19 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén karl.kil...@gmail.com wrote: Tried 2.2.2-20140313.024403-5 Duplicate id problems are still present. I have tried for a while now to create a simple sample but I am unsuccessful so far. +1 thanks Karl for the report.
Re: 2.2 stability
Hi 2014-03-10 14:13 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com: response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com wrote: Hi Howard, If someone proposed a fix for me I must have missed it, so no my issues are still not resolved unfortunately. I don't think it's possible to write it in another fashion. Leonardo's response, asking you to try MyFaces 2.2.1, which was released within the last 12 to 24 hours. :) Yes. If there is a bug in 2.2.1 and there is evidence, I'll do my best for fix it. Problem #1: enctype=multipart/form-data not working. Not sure if anyone tried the demo app I linked in the jira but for now I can't investigate it any further on my own. i don't think Leonardo's response was targeting this issue. maybe/hopefully, Leonardo will respond at his earliest convenience. earlier, did you say that this issue is resolved via Mojarra 2.2.x (and some other container... glassfish, jboss, ...) ??? I have read JSF 2.2 spec fully and there is no special part related to multipart encoding. I don't see how it can work, maybe it is something not documented. I'll review the issue and check an example against latest Mojarra. Problem #2 I also have a problem with duplicated id's but it would take some time to reproduce it in a demo app so I'm hesitant to bring it up. Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some bindings :-) did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is fixed in your app/project? is it best to assume that c:forEach is supposed to work with/via AJAX PPR? just because Mojarra 'works', should we assume that Mojarra's implementation is correct? Let's go to clarify this. First of all, c:forEach has been a broken tag for year. Most people has found many bugs, most of them related to its particular behavior. Since facelets was donated to both Mojarra and MyFaces, both share the same code and has the same problems. Mojarra has not done anything to fix the problems, so they still have the old code, but in MyFaces 2.2.x branch we have tried to fix it once for all. The problem is sometimes in some situations the old code (in Mojarra) works, but in others it just doesn't, it fails in the form of duplicate id exceptions or the state get lost, but for the user point of view sometimes it looks like things are working but it is not, it is rotten from the inside. So, the old code is not an option, because it is the worst possible option. The new solution is the way to go, because it solves the problem from root. So, Mojarra implementation is not correct, but just by luck it works in some situations. The solution in MyFaces 2.2.1 is the best we have so far, works in most cases and if there is a bug (I'm working on MYFACES-3867, which claims a problem in a very specific complex case) we'll fix it. I know all this has been annoying and painful, that's the reason why we did it in 2.2.x only, but if we can fix it, it will be great because the component tree will use always PSS in those dynamic parts and that means lower state size, lower session size and better overall performance. MyFaces and TomEE committers know that there MyFaces may be a bit more 'strict' than Mojarra (I can agree with that as well, as per my experience when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces (and TomEE) committers question the fact that Mojarra is really meeting requirements of the spec, or there is a different set of TCKs that Mojarra is running against. I hope 'they' will confirm, clarify, or correct what I'm stating here. :) In few words, the vision of MyFaces is comply with the spec. But that does not mean that MyFaces will be bug-compatible with Mojarra. I think the code is very good from spec point of view, and each issue found that it has been solved in a different way has been widely discussed. What's happening here is the TCK does not cover a lot of edge cases, and since MyFaces is widely used and many people gives a lot of good quality feedback, it has been possible to fix a lot of issues that Mojarra has not seen yet, or has not been fixed in the right way. One way to see the quality of the code is take a look at the amount of issues solved in each version. In 2.0.10 we solved 72 issues but in 2.0.21 we solved just 2. In 2.2.1 we solved only 12. regards, Leonardo Uribe
Re: 2.2 stability
Hi Karl 2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com: Hi Leo, Upgraded to 2.2.1 today (or was it yesterday?) and had problems. Removed org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY and many problems went away. Much later discovered more problems but it's just me and my silly app until I have proof :-) I totally agree that c:forEach was more broken before! Thanks a lot for fixing it. I have found the problem related to MYFACES-3867, so I have already fixed the code in trunk. I think this bug deserves a quick-fix release. I would be very interested in some more input / clarifications about my other problem actually. Are you saying that forms may not use enctype=multipart/form-data? How are you supposed to fileUpload? Perhaps you must have a fileUpload component present if the form has enctype=multipart/form-data? Sounds like a weird limitation. My functional requirement is of course a form with a fileupload component, it is not working though and it's because the form will not post. I ended up removing all markup until I had a single button in a form and it still did not work, that's when I created a jira. But at one point that form did have a fileupload too with no difference in the result. The example provided by Michael Kurz in: https://github.com/jsflive/jsf22-examples/blob/master/jsf22-input-file/src/main/webapp/upload.xhtml h:form id=form enctype=multipart/form-data h:messages/ h:panelGrid columns=2 h:outputText value=File:/ h:inputFile id=file value=#{uploadPage.uploadedFile} validator=#{uploadPage.validateFile}/ /h:panelGrid h:commandButton value=Upload File action=#{uploadPage.uploadFile}/ h:commandButton value=Upload File (Ajax) action=#{uploadPage.uploadFile} f:ajax execute=file render=@all/ /h:commandButton h:panelGrid id=content columns=1 h:outputText value=Content:/ h:inputTextarea readonly=true value=#{uploadPage.fileContent} rows=10 cols=100/ /h:panelGrid /h:form Look the enctype=multipart/form-data is there, but the code also needs the h:inputFile. I don't see how it can work with just the button. h:form id=mainForm enctype=multipart/form-data h:commandButton value=Press me action=# {bean.test}/br/ /h:form I can see the example in the rar file: h:form id=mainForm enctype=multipart/form-data h:panelGrid columns=2 h:outputLabel for=name value=Please enter your name/ h:inputText id=name value=#{helloWorld.name} required=true/ /h:panelGrid h:commandButton value=Press me action=#{helloWorld.send}/br/ h:messages showDetail=true showSummary=false/ /h:form but the same, it requires the h:inputFile so the file is uploaded. Servlet 3.0 implementation handles the request, and JSF uses the spec, so if the servlet spec works JSF should work. regards, Leonardo Uribe On 10 March 2014 21:01, Leonardo Uribe lu4...@gmail.com wrote: 2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com: Ah the new release, yes I tried it asap it did not fix my issue. Which one? #1 or #2 ? Regarding the duplicated id issue that I think could be related to c:forEach, No idea what the problem is but it works fine with mojarra and just as fine with myfaces 2.1.x. The construct in that app is special so it is up to me to reproduce it and I don't have time until next week. And yes, c:forEach works with ajax but it's important that the items are unchanged during postback. Ok. If we have an example we will be able to fix it more quickly. For now I'll take a look at MYFACES-3867 I am considering mojarra because enctype=multipart/form-data is not working for me with any myfaces 2 version. It's common knowledge that Mojarra is skimping on some validation here and there. On 10 March 2014 20:13, Howard W. Smith, Jr. smithh032...@gmail.com wrote: response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com wrote: Hi Howard, If someone proposed a fix for me I must have missed it, so no my issues are still not resolved unfortunately. I don't think it's possible to write it in another fashion. Leonardo's response, asking you to try MyFaces 2.2.1, which was released within the last 12 to 24 hours. :) Problem #1: enctype=multipart/form-data not working. Not sure if anyone tried the demo app I linked in the jira but for now I can't investigate it any further on my own. i don't think Leonardo's response was targeting this issue. maybe/hopefully, Leonardo will respond at his earliest convenience. earlier, did you say that this issue is resolved via Mojarra 2.2.x (and some other container... glassfish, jboss, ...) ??? Problem #2 I also have a problem
Re: 2.2 stability
Hi @MYFACES-3865 It was fixed in 2.2.1, and the artifacts will be released in no time. The fix for c:forEach was really complex and painful, but it was finally done and the result is the best option we will have. Finally we have a proper solution that will work in complex cases and will allow all facelets dinamic tags to work well together. The hack done for: org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY Is meant for people that requires the old (and buggy) logic from facelets 1.1.x, so it is expected to do not work in some cases. My personal perception is 2.2.1 will be very stable, it is obvious to have some small bugs, but in this release we created a lot of junit tests, so the probability of find bugs has become small. Anyway, we will be eager to check and fix all new issues as soon as possible. regards, Leonardo Uribe 2014-03-09 18:26 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr wrote: I found 2.2 to be very stable, almost a drop in replacement for 2.1. +1 I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and MyFaces 2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied with myFaces 2.2.0, and i have had 'no' issues at all. :)
[ANNOUNCE] MyFaces Core v2.0.21 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.21. MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.21 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.0.21 Bug [MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional link parameters when checking for the resource [MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL in processUpdates regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.1.15 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.1.15. MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.1.15 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.1.15 Bug [MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional link parameters when checking for the resource [MYFACES-3850] - html EL expression inside markup enables escape on static text in facelets jspx mode [MYFACES-3854] - oam-compress-spaces remove carriage return / line feed in CDATA sections [MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL in processUpdates regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.1 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.1. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.1 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 2.2.1 Bug [MYFACES-3845] - Invalid modification of facesConfig.getFacesFlowDefinitions() collection when implicit flow definition is derived [MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional link parameters when checking for the resource [MYFACES-3850] - html EL expression inside markup enables escape on static text in facelets jspx mode [MYFACES-3853] - ui:include not working inside c:forEach [MYFACES-3854] - oam-compress-spaces remove carriage return / line feed in CDATA sections [MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL in processUpdates [MYFACES-3858] - Faces Flow startNode is not defined by default for xml non empty files ending with -flow.xml [MYFACES-3859] - Allow use the flowId as a nodeId inside the same flow [MYFACES-3860] - UIViewRoot.restoreViewScopeState(...) is not being called from DefaultFaceletsStateManagementStrategy [MYFACES-3861] - impl-test module using unpack plugin does not allow generate site Improvement [MYFACES-3846] - Implement temporal resourcehandler cache for JSF 2.2 contracts [MYFACES-3862] - Set mock InitialContextFactory for junit testing with myfaces impl test regards, Leonardo Uribe
Re: 2.2.0 and multipart
Hi I can confirm a simple example using MyFaces 2.2.0 works. See: http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/ I think the problem is caused by some kind of incompatibility from primefaces p:fileUpload. h:inputFile relies on servlet 3.0 spec, but p:fileUpload could still use the filter approach, so you need to put a filter on top of faces servlet to handle the multipart request. Theoretically, nothing has changed, or at least at first view I cannot see a problem in MyFaces besides the issues we have already fixed, so 2.2.0 should not have any problem. It could be great if you can provide an example webapp showing the problem, so we can take a look with the debugger and see if there is a problem from primefaces or from myfaces. For now the evidence I have suggest MyFaces is ok. regards, Leonardo Uribe 2014-02-25 10:36 GMT-05:00 Leonardo K. Shikida shik...@gmail.com: Thanks Em 25/02/2014 12:20, Howard W. Smith, Jr. smithh032...@gmail.com escreveu: On Tue, Feb 25, 2014 at 3:20 AM, Werner Punz werner.p...@gmail.com wrote: Am 22.02.14 02:58, schrieb Leonardo K. Shikida: Hi Just noticed this thread about tomee, myfacs 2.2.0 and multipart request stackoverflow.com/questions/21948228/how-to-get-jsf-file- upload-to-work-on-tomee-1-6 does anyone know if between 2.1.13 and 2.2.0, multipart request has got any new bug? could not find anything in JIRA the guy who posted the stackoverflow question tested with h:commandButton while I've reproduced the problem just switching myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using p:fileUpload [] Leo Hi this could be a new bug, we introduced a fileupload handling with JSF 2.2 (the h:inputFile tag) maybe the normal multipart request handling was broken by the extensions done in this area the best bet is to file a bugreport in the myfaces bugtracker https://issues.apache.org/ jira/browse/MYFACES Werner +1 thanks Leonardo for informing the user list about this issue. I am using MyFaces 2.2 (and/via TomEE 1.6.1 snapshot) with my JSF web application, and I confirmed this bug/issue too in my app. PrimeFaces 4.x (simple) fileUpload is no longer working. :( maybe, it can/should be confirmed if MyFaces 2.2 (basic/simple) fileUpload works as designed/expected. i have not tested that though/yet.
[ANNOUNCE] release of myfaces master pom v 15
The Apache MyFaces team is pleased to announce the release of myfaces master pom v 15. This pom is used internally by define default configuration and community information shared by all myfaces projects and used when site deployment and reports are executed. You can find it in the maven repo unde the group org.apache.myfaces.myfaces. http://repo2.maven.org/maven2/org/apache/myfaces/myfaces/15/myfaces-15.pom regards, Leonardo Uribe
Re: Composite components in myfaces 2.2.
Hi I think the problem is mix ui:composition with cc:interface or cc:implementation. The compiler check these tags and do some special steps. Just use other different tag like this. html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; regards, Leonardo Uribe 2014-02-24 15:01 GMT-05:00 Michael Kurz michi.k...@gmx.at: Maybe you are missing a faces-config.xml in the jar inside META-INF. JSF won't scan the jar otherwise. See my post at JSFlive [1] for details. Best regards Michi [1]: http://jsflive.wordpress.com/2011/03/24/custom-component-library/ Am 24.02.2014 13:26, schrieb Johannes Murth: The output of DOCTYPE was related to another issue: The XHTML that is embedded with ui:include had this as root element. ui:composition as root element solved the problem. - Side question: is this an official change from 2.1 to 2.2? But there is still the issue that the composite component from the JAR is not found: The using page looks like this: xmlns:xma=http://openxma.codehaus.org/xmajsf; ... xma:navbar .. brand=Test / .. /... The component is in somelib.jar/META-INF/resources/xmajsf/navbar.xhtml and looks like this Beside there is a xmajsf.taglib.xml in the root of the same JAR: ui:composition xmlns=http://www.w3.org/1999/xhtml; xmlns:cc=http://java.sun.com/jsf/composite; xmlns:ui=http://java.sun.com/jsf/facelets; cc:interface componentType=Navbar cc:attribute name=brand required=true/ /cc:interface cc:implementation ... /cc:implementation /ui:composition Beside there is this content in META-INF\xmajsf.taglib.xml inside the same JAR: facelet-taglib version=2.0 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd; namespacehttp://openxma.codehaus.org/xmajsf/namespace composite-library-namexmajsf/composite-library-name /facelet-taglib What am I doing wrong? 2014-02-14 17:52 GMT+01:00 Michael Kurz michi.k...@gmx.at: Hi, would be interesting how your composite component looks like (the basic structure) and how it is embedded in the page. Best regards Michi Am 13.02.2014 13:10, schrieb Johannes Murth: Hi! I just upgraded from 2.1 to 2.2 and have rendering problem because xml doctype and html tag are rendered right before composite component. These break the layout and should just be swallowed. Thanks for any advice!
Re: @FlowScoped, @Named and @ManagedBean
Hi I forgot to say what's wrong in the xml file is define the start node. I have created and fixed this issue on: https://issues.apache.org/jira/browse/MYFACES-3858 regards, Leonardo Uribe 2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 13/02/2014 19:01, Leonardo Uribe wrote: Hi Thanks for the example. It helps to clarify the problem. The definition of the flow has a problem: @Produces @FlowDefinition public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = flux; flowBuilder.id(, flowId); flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); /*flowBuilder.returnNode(returnFromFlux). fromOutcome(#{flowScopedBean.return});*/ return flowBuilder.getFlow(); } In this part: flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); you are using the flow id as a viewNodeId. That confuses the navigation algorithm because the spec says that an outcome can be a flowId, and in that sense a flowId is a global identifier that cannot be reused. The fix is just set another id: flowBuilder.viewNode(start, / + flowId + / + flowId + .xhtml). markAsStartNode(); The example only requires some small changes in FlowScopedBean and that's it. ok for this one, I will try it tomorrow. And can you tell me what was wrong with XML file (or the empty XML file) ? Thank you, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
Hi I also did some changes in the navigation to deal with the case when the nodeId has the same name as the flow in: https://issues.apache.org/jira/browse/MYFACES-3859 Please note in a normal case click to enter into a flow twice (enter into a flow, navigate and try to enter into the same flow again) cause get out of the flow and enter into the flow again, which is expected. But in this case, the resulting flow will not have that behavior and instead the navigation goes to the node identified as start node without exit from the flow. regards, Leonardo Uribe 2014-02-19 20:05 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi I forgot to say what's wrong in the xml file is define the start node. I have created and fixed this issue on: https://issues.apache.org/jira/browse/MYFACES-3858 regards, Leonardo Uribe 2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 13/02/2014 19:01, Leonardo Uribe wrote: Hi Thanks for the example. It helps to clarify the problem. The definition of the flow has a problem: @Produces @FlowDefinition public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = flux; flowBuilder.id(, flowId); flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); /*flowBuilder.returnNode(returnFromFlux). fromOutcome(#{flowScopedBean.return});*/ return flowBuilder.getFlow(); } In this part: flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); you are using the flow id as a viewNodeId. That confuses the navigation algorithm because the spec says that an outcome can be a flowId, and in that sense a flowId is a global identifier that cannot be reused. The fix is just set another id: flowBuilder.viewNode(start, / + flowId + / + flowId + .xhtml). markAsStartNode(); The example only requires some small changes in FlowScopedBean and that's it. ok for this one, I will try it tomorrow. And can you tell me what was wrong with XML file (or the empty XML file) ? Thank you, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: Error with c:if inside next c:forEach MyFaces 2.2.0
Hi It looks like a page processed by facelets, not by JSP. Between 2.2.0-beta and 2.2.0 we did a change in c:forEach tag. The improvement is ok, but according to the stack trace I can see a problemn with the id generation. I recently fixed this issue: https://issues.apache.org/jira/browse/MYFACES-3853 It looks like something related. If the id generation is correct, c:forEach and c:if receive different ids. The old algorithm in c:forEach did not have an associated id. Could you please try with the latest snapshot available here? https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/ regards, Leonardo Uribe 2014-02-18 21:20 GMT-05:00 Najy Nicolas najy.nico...@gmail.com: Hi, I have a c:if tag inside 3 nested for loops in a JSP file. I get an error only when I add the c:if to the JSP... I only got the error when I upgraded to MyFaces 2.2.0. The same JSP worked fine when I used MyFaces 2.2.0-beta c:forEach var=table items=#{myBean.tables} c:forEach var=row items=#{table.rows} c:forEach var=cell items=#{row.cells} c:if test=#{cell.visible} #{cell.comeValue} /c:if c:forEach/ c:forEach/ c:forEach/ WARNING: JSF error handler: java.lang.ClassCastException: java.lang.Boolean cannot be cast to org.apache.myfaces.view.facelets.tag.jstl.core.IterationState at org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:210) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.applyFirstTime(ForEachHandler.java:382) at org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:229) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240) at org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226) at org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.applyFirstTime(ForEachHandler.java:382) at org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:229) at org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240) at org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226) at org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240) at org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226) at org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:55
[ANNOUNCE] MyFaces Test v1.0.6 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Test 1.0.6. The Myfaces Test Framework provides mock object libraries, plus base classes for creating your own JUnit TestCases for JSF. For more information please see: http://myfaces.apache.org/test MyFaces Core is available in the central Maven repository under Group ID org.apache.myfaces.test. Release Notes - MyFaces Test - Version 1.0.6 Bug [MYFACESTEST-64] - MockMethodExpression should throw MethodNotFoundException Improvement [MYFACESTEST-67] - Allow use servlet listeners inside mocks [MYFACESTEST-68] - Set Location header on redirect for mock New Feature [MYFACESTEST-65] - Implement HttpServletRequest.isUserInRole(String) [MYFACESTEST-66] - pre-configured containers regards, Leonardo Uribe
Re: @FlowScoped, @Named and @ManagedBean
Hi Thanks for the example. It helps to clarify the problem. The definition of the flow has a problem: @Produces @FlowDefinition public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) { String flowId = flux; flowBuilder.id(, flowId); flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); /*flowBuilder.returnNode(returnFromFlux). fromOutcome(#{flowScopedBean.return});*/ return flowBuilder.getFlow(); } In this part: flowBuilder.viewNode(flowId, / + flowId + / + flowId + .xhtml). markAsStartNode(); you are using the flow id as a viewNodeId. That confuses the navigation algorithm because the spec says that an outcome can be a flowId, and in that sense a flowId is a global identifier that cannot be reused. The fix is just set another id: flowBuilder.viewNode(start, / + flowId + / + flowId + .xhtml). markAsStartNode(); The example only requires some small changes in FlowScopedBean and that's it. regards, Leonardo Uribe 2014-02-13 6:03 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 13/02/2014 01:44, Leonardo Uribe wrote: [...] This is an edge case. Theorically it should work. Could you please provide the stack trace, so I can investigate it further?. Please find attached a mini maven project reproducing the «bug» (or maybe a PBKAC there :-) ). If you just build and debug it, you will be in the situation I just described. If you disable the Flux description bean (I just comment the @Produces and @FlowDefinition annotations to do that) and rename src/main/webapp/flux/flux-flow-empty.xml or src/main/webapp/flux/flux-flow-simple.xml to src/main/webapp/flux/flux-flow.xml you will be able to test the other situations I described. Thanks again ! Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
...@gmail.com wrote: Can't you just switch to DS? 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com javascript:; : Hi CDI implementations does not require to provide anything to JSF in order to make @FlowScoped to work. The code has been tested against OWB and Weld and it works in both cases. But the flow stuff relies on the new ClientWindow API, and that could cause a conflict with CODI, because CODI provides a solution for this part too. In fact, the solution introduced in the standard comes from CODI. In your particular case, the best option is provide a custom ClientWindowFactory / ClientWindow that implements ClientWindow.getId() method and grab the value generated by CODI. Theorically there is no need of the custom PhaseListener, because the attachWindow step is done in CODI. I haven't tried it but I suppose a custom ClientWindow will work. regards, Leonardo Uribe 2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 11/02/2014 14:51, l.pe...@senat.fr wrote: On 11/02/2014 10:28, l.pe...@senat.fr wrote: On 11/02/2014 03:30, Leonardo Uribe wrote: [...] @FlowScoped annotation is for CDI only, so it will not work for JSF managed beans. In your case, I believe the bean is instantiated but it is not stored in any context, so once is created is discarded, giving the impression that the bean is working but it is not. -- ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
Re: @FlowScoped, @Named and @ManagedBean
Hi CDI implementations does not require to provide anything to JSF in order to make @FlowScoped to work. The code has been tested against OWB and Weld and it works in both cases. But the flow stuff relies on the new ClientWindow API, and that could cause a conflict with CODI, because CODI provides a solution for this part too. In fact, the solution introduced in the standard comes from CODI. In your particular case, the best option is provide a custom ClientWindowFactory / ClientWindow that implements ClientWindow.getId() method and grab the value generated by CODI. Theorically there is no need of the custom PhaseListener, because the attachWindow step is done in CODI. I haven't tried it but I suppose a custom ClientWindow will work. regards, Leonardo Uribe 2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: On 11/02/2014 14:51, l.pe...@senat.fr wrote: On 11/02/2014 10:28, l.pe...@senat.fr wrote: On 11/02/2014 03:30, Leonardo Uribe wrote: [...] @FlowScoped annotation is for CDI only, so it will not work for JSF managed beans. In your case, I believe the bean is instantiated but it is not stored in any context, so once is created is discarded, giving the impression that the bean is working but it is not. In MyFaces it is possible to create a custom flow scope annotation for other containers that works just like @FlowScoped, implementing org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are already in CDI, so you don't need to bother about that. I have seen @Named annotation working with Spring, so it is not something specific for CDI, but @FlowScoped depends of CDI API. I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped annotation) with OpenWebBeans 1.2.1. So, I thought was ok on the CDI side... ...but after reading your mail, it seems to me that this CDI implementation was provided before JSF 2.2 release, and so that it must not include proper @FacesFlow support. Should I switch to another implementation, like DeltaSpike ? I must have misunderstood your mail from Sep 26 2013 ( http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852.html ) inviting us to try Faces Flows in MyFaces 2.2. After some debugging, I found that : * beans are discovered and processed ok by org.apache.myfaces.flow.cdi.FlowScopeCDIExtension * -flow.xml is detected and processed with no errors ; * if I use an empty -flow.xml file, an exception is raised line 716 of org.apache.myfaces.config.DefaultFacesConfigurationProvider (on facesConfig.getFacesFlowDefinitions().add(flow); ) * if I add a breakpoint in org.apache.myfaces.flow.FlowHandlerImpl#clientWindowTransition, I can see : ** my flow registered in _flowMapById (with flow1 key) ** my flow registered in _flowMapByDocumentId (with an empty key) ** that _facesFlowProvider is null ok, I think I got it. And, as I feared, it seems to be CODI related. In JSF2.2, a call to //JSF 2.2: attach window _lifecycle.attachWindow(facesContext); has been added line 193 of javax.faces.webapp.FacesServlet When you use CODI, _lifecycle is an instance of org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper This wrapper has been designed for JSF 2.0 and 2.1. So, it does not wrap the call to attachWindow. And Lifecycle#attachWindow, which does nothing, is called. Later, when JSf tries to find my @FlowScoped bean, it fails in org.apache.myfaces.flow.FlowHandlerImpl#getCurrentFlow , because client windos is null (line 165 and following) : ClientWindow clientWindow = context.getExternalContext().getClientWindow(); if (clientWindow == null) { return null; } So, I guess that I have to write a custom PhaseListener to solve this little glitch. If you have a better solution, I will gladly take it. Best regards, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: @FlowScoped, @Named and @ManagedBean
Hi 2014-02-10 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr: Dear all, I am starting to really use JSF 2.2. I am trying to use Faces Flows. I am starting with a very simple flow, whose name is flow1. So, under src/main/webapp, I have a flow1 directory containing flow1-flow.xml flow1.xhtml flow1b.xhtml flow1-flow.xml contains : ?xml version=1.0 encoding=UTF-8? faces-config xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns='http://xmlns.jcp.org/xml/ns/javaee' xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd' version='2.2' flow-definition id=flow1 flow-return id=returnFromFlow1 from-outcome/accueil/from-outcome /flow-return /flow-definition /faces-config With such a simple config, using conventions would be a better choice than configuration, but I plan to add more things to it... :-) I use a @FlowScoped bean declared this way : @Named @FlowScoped(flow1) public class MinintFileContext implements Serializable { } and it does not work. I have the following exception : javax.servlet.ServletException: javax.servlet.ServletException: javax.el.ELException: javax.enterprise.context.ContextNotActiveException: WebBeans context with scope type annotation @FlowScoped does not exist within current thread To make it work, I have to use @ManagedBean instead of @Named. My first question is : I do not understand why... In my (obviously wrong) understanding, @Named was a super-set of CDI-managed beans, including @ManagedBean-s. @FlowScoped annotation is for CDI only, so it will not work for JSF managed beans. In your case, I believe the bean is instantiated but it is not stored in any context, so once is created is discarded, giving the impression that the bean is working but it is not. In MyFaces it is possible to create a custom flow scope annotation for other containers that works just like @FlowScoped, implementing org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are already in CDI, so you don't need to bother about that. I have seen @Named annotation working with Spring, so it is not something specific for CDI, but @FlowScoped depends of CDI API. Another question... I am using PrimeFaces p:menubar . I noticed that I can not use /flow1 as the outcome of a menuitem Ex : p:menuitem value=Blah blah blah outcome=/flow1 / I have to use p:menuitem value=Blah blah blah outcome=/flow1/flow1 / Why ? This might be a PF-specific question. Try in this way: p:menuitem value=Blah blah blah outcome=flow1 / If you put /flow1 as outcome, the navigation algorithm will interpret this as a normal navigation to a page (/flow1.xhtml), so the flow scope will not be activated and the bean will not be instantiated correctly. It should work without any changes in primefaces, because the outcome should be calculated using ConfigurableNavigationHandler.getNavigationCase(...). Finally, I am failing to use the flow-return configuration. I tried p:commandButton value=Terminer action=returnFromFlow1/ and h:commandButton value=Terminer action=returnFromFlow1/ But it just does not work. So, I tried to change the config to flow-return id=returnFromFlow1 from-outcome#{minintFileContext.returnValue}/from-outcome /flow-return and added a public String getReturnValue() { return /accueil; } method to he MinintFileContext bean, but it does not work better. Any idea ? Try it again, maybe the reason is that it seems you are inside the flow but it is not. You can check if you are in the flow using facesContext.getApplication().getFlowHandler().isActive(...). regards, Leonardo Uribe Thanks in advance I have the following JSF-related or generic dependencies (I mean that I remove in-house dependencies from the following tree) : [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ faces-dependencies --- [INFO] fr.senat:faces-dependencies:jar:4.0.0-SNAPSHOT [INFO] +- commons-lang:commons-lang:jar:2.6:compile [INFO] +- org.apache.commons:commons-lang3:jar:3.1:compile [INFO] +- org.apache.tomcat:tomcat-catalina:jar:7.0.47:provided [INFO] | +- org.apache.tomcat:tomcat-servlet-api:jar:7.0.47:provided [INFO] | +- org.apache.tomcat:tomcat-juli:jar:7.0.47:provided [INFO] | +- org.apache.tomcat:tomcat-annotations-api:jar:7.0.47:provided [INFO] | +- org.apache.tomcat:tomcat-api:jar:7.0.47:provided [INFO] | \- org.apache.tomcat:tomcat-util:jar:7.0.47:provided [INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.0:compile [INFO] +- org.apache.myfaces.core:myfaces-impl:jar:2.2.0:compile [INFO] | +- commons-collections:commons-collections:jar:3.2:compile [INFO] | +- commons-codec:commons-codec:jar:1.3:compile [INFO] | +- commons-beanutils:commons-beanutils:jar:1.8.3:compile [INFO] | | \- commons-logging:commons
Re: StackOverflowError with MyFaces 2.2.0
Hi The stack trace suggest there is a problem in the classpath. There should be a copy of javax.faces api somewhere that is making a conflict. regards, Leonardo Uribe 2014/1/22 Howard W. Smith, Jr. smithh032...@gmail.com: On Wed, Jan 22, 2014 at 1:50 PM, Mike Calmus m...@calmus.org wrote: I tried updating an existing application to MyFaces 2.2.0 (from 2.1.11) by simply replacing the library. Interesting. I'm sure that I could have migrated my app from MyFaces 2.1.11 to myFaces 2.2.0, but I'm using TomEE, which has a nice home for MyFaces 2.1.x (and MyFaces 2.2.x). Library = api and impl JAR or library = bundle JAR ? When I try to deploy the app, I get a StackOverflowError (below). Might be good for you to copy/paste your (entire) server log (on startup of server/app) to pastebin website or provide that in your next reply.
Re: JSF 2.2 Exit Flow
Hi You can do what you want creating a custom ViewHandler and overriding createView(...) method like this: @Override public UIViewRoot createView(FacesContext context, String viewId) { UIViewRoot root = super.createView(context, viewId); if (root != null) { FlowHandler flowHandler = context.getApplication().getFlowHandler(); if (flowHandler.isActive(context, , flow1) !viewId.startsWith(/flow1/)) { Flow flow = flowHandler.getFlow(context, , flow1); flowHandler.transition(context, flow, null, null, viewId); } } return root; } The code just check when the flow is active and if the view belongs to the flow. If the navigation goes out of the flow it send a trasition ending the flow. Really this topic is being discussed under the EG, see: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1253 Let's see what happen. regards, Leonardo Uribe 2014/1/18 Gerhard Petracek gerhard.petra...@gmail.com hi geoffrey, just fyi (in addition to the answer from michael): that's one of the major use-cases we had for codi/deltaspike (grouped-)conversations. you can use a listener (or an observer for PreViewConfigNavigateEvent + custom view-config meta-data) which just calls (WindowContext#closeConversations in case of codi or GroupedConversationManager#closeConversations in case of deltaspike). regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2014/1/18 Michael Kurz michi.k...@gmx.at Hi, as far as I know, this is currently not possible. JSF won't let you navigate to something that is not defined as a node in the current flow. I quickly talked to Ed Burns about this some time ago and he more or less confirmed that this is the case. Regards Michael Am 17.01.2014 02:10, schrieb Geoffrey Longo: I have an application that consists of a dropdown menu bar with many menu items. Each menu item will initiate a new faces flow. This is working correctly, however, once I am inside a flow, I would like any click on a menu item to exit the current flow, and then start a new one. There are dozens of menu items in the application, so I was wondering if there is any way to have the current flow automatically exit when a menu item is clicked without having to define a flow-return for each menu item? Thanks, Geoff
Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException
Hi It looks like something not directly related to MyFaces, it is like if the classpath is scanned twice, or like the bean is subscribed twice. I suppose it is a bug in OWB or in TomEE. Maybe you should report it in: https://issues.apache.org/jira/browse/TOMEE regards, Leonardo Uribe 2014/1/15 José Luis Cetina maxtorz...@gmail.com: Hi. I use TomEE 1.6.0 Final release with myfaces 2.1.13 and jdk 1.7 with this i was using the org.omnifaces.cdi.ViewScoped annotation with any problem, with the new release of myfaces 2.2.0 i decide to change from org.omnifaces.cdi.ViewScoped to javax.faces.view.ViewScoped then im gettin this AmbiguousResolutionException. This error only happend in Linux environment, if i run the same project in Windows this error never appears. I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces api and impl 2.2.0 What could be wrong? Log: javax.enterprise.inject.AmbiguousResolutionException: Ambiguous resolution found beans: ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] from jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder], Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] from jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionExceptionForBeans(InjectionExceptionUtil.java:104) org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:94) org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:71) org.apache.webbeans.container.InjectionResolver.resolve(InjectionResolver.java:699) org.apache.webbeans.container.BeanManagerImpl.resolve(BeanManagerImpl.java:925) org.apache.webbeans.container.InjectableBeanManager.resolve(InjectableBeanManager.java:201) org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:413) org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:144) org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.getViewScopeBeanHolder(CDIManagedBeanHandlerImpl.java:64) org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.generateViewScopeId(CDIManagedBeanHandlerImpl.java:92) org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76) org.apache.myfaces.view.ViewScopeProxyMap.size(ViewScopeProxyMap.java:89) javax.faces.component.UIViewRoot.saveState(UIViewRoot.java:1498) org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:846) org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:351) org.apache.myfaces.renderkit.ErrorPageWriter.handle(ErrorPageWriter.java:470) org.apache.myfaces.context.MyFacesExceptionHandlerWrapperImpl.handle(MyFacesExceptionHandlerWrapperImpl.java:301) javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:61) org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:162) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:287) javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
Re: [ANNOUNCE] MyFaces Core v2.2.0 Release
Hi Howard 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Leonardo, Some questions for you: 1. How has MyFaces 2.2 (beta) release been performing and/or accepted by MyFaces user community? We have received some good feedback that has helped a lot to get the new release. 2. Any big corporation/names start using MyFaces 2.2 (beta) release yet? If things goes like it was in 2.0, it still will take a couple of releases so more people start using fully the new artifacts, but since we are 2.2 I hope the adoption will be faster. 3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)? Yes, there are some improvements in session size / state management that will help. From speed perspective, with the same flags enabled both perform more or less the same. 4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2 performance against Mojarra, Wicket, and Spring...like you did for MyFaces 2.1.7? Probably, but more as an update to keep track what has happened. regards, Leonardo Uribe Thanks, Howard On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org wrote: The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.0.
Re: [core] What's new in MyFaces 2.2
Hi 2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com: Wow, interesting that you sent this email as I was writing my email, asking a few questions bout MyFaces 2.2. Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me to think about MyFaces 2.2. I am considering migrating my app from MyFaces 2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and since the last time that I tested/used myFaces 2.2, I have no issues/defects to report. Just have not pushed MyFaces 2.2 to my production environment yet. The changes included in JSF 2.2 does not make any conflict with 2.0 / 2.1 code. The migration step from 2.1 to 2.2 is very simple, just replace the jars and that's it. There are some differences like for example the view scope beans are now stored in session and if CDI is enabled, view scope is managed by CDI. Additionally, there wasn't any change that affect the behavior significantly in JSF 2.2, so the code looks very stable. It were also included a lot of junit tests for the new features to ensure everything works as expected, which reduces in the long term the occurrence of bugs and provides a better code quality. I wanted to wait and hear a bit more from the community about it, but (LOL) that's the thing, there are not many questions at all on MyFaces user list. Evidently, it just works! :) On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org wrote: Hi For the people who want to know quickly what's new in MyFaces 2.2, I have written a summary of the new features here: http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.0.20 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.0.20.MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.20 is available in both binary and source distributions.* http://myfaces.apache.org/download.htmlMyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core.Bug[MYFACES-3835] - ViewState gets truncated on chrome with richfaces fileupload component [MYFACES-3836] - f:ajax disabled=false in commandButton with onclick prevents form submission[MYFACES-3837] - ui:debug renders an amp; but it should be because the markup is inside a CDATA sectionTask [MYFACES-3827] - Replace .xsd with the ones from geronimo or written from scratchregards,Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.1.14 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.1.14. MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant with the JSR-314 specification. MyFaces Core 2.1.14 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Bug [MYFACES-3829] - alwaysRecompile logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup [MYFACES-3831] - CacheELFaceletCacheImpl is not storing the compiled template (only when alwaysRecompile is enabled) [MYFACES-3835] - ViewState gets truncated on chrome with richfaces fileupload component [MYFACES-3836] - f:ajax disabled=false in commandButton with onclick prevents form submission [MYFACES-3837] - ui:debug renders an amp; but it should be because the markup is inside a CDATA section Task [MYFACES-3827] - Replace .xsd with the ones from geronimo or written from scratch regards, Leonardo Uribe
[ANNOUNCE] MyFaces Core v2.2.0 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Core 2.2.0. MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by JSR-344. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). MyFaces Core 2.2.0 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Bug [MYFACES-3820] - UIInput.setSubmittedValue() cause recursive call when calling getSubmittedValue() on Debug [MYFACES-3821] - Implement UIData.setDataModel(...) [MYFACES-3824] - @FlowScope with no defining documentId set cannot found active flow with explicit documentId [MYFACES-3829] - alwaysRecompile logged as wrong value for org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup [MYFACES-3830] - Component created using @FacesComponent with createTag=true and @ResourceDependency makes initialization fail [MYFACES-3831] - CacheELFaceletCacheImpl is not storing the compiled template (only when alwaysRecompile is enabled) [MYFACES-3832] - disableClientWindow is not fully implemented [MYFACES-3834] - Restore org.apache.myfaces.config.impl.digester.elements.FacesConfig to avoid tomee integration to fail [MYFACES-3835] - ViewState gets truncated on chrome with richfaces fileupload component [MYFACES-3836] - f:ajax disabled=false in commandButton with onclick prevents form submission [MYFACES-3837] - ui:debug renders an amp; but it should be because the markup is inside a CDATA section [MYFACES-3838] - LegacyUserTagHandler should implement ComponentContainerHandler [MYFACES-3839] - Relative implicit link not found when it reference parent nodes. Improvement [MYFACES-3804] - Use the same key in server side state saving for ajax requests [MYFACES-3806] - Destroy ViewScope beans when view is discarded from view state. [MYFACES-3815] - Lazy instantiation of Renderer classes [MYFACES-3819] - Allow override resource components using a tag handler [MYFACES-3823] - [perf] use a preinitialized table of unique ids for UIViewRoot.createUniqueId(...) [MYFACES-3825] - [perf] Cache EL expressions using an indirection for ui:param and user tag attributes [MYFACES-3828] - [perf] Do not store the namespace into state for dynamic components New Feature [MYFACES-3664] - JSF View Pooling (going beyond JSF Stateless Mode) Task [MYFACES-3647] - remove JspStateManagerImpl and other unused stuff in this area [MYFACES-3715] - Remove unnecessary parameters or features from earlier versions in MyFaces 2.2 [MYFACES-3809] - Add http://java.sun.com/jstl/core as a valid namespace for c jstl library in facelets [MYFACES-3810] - Add compatibility mode for facelets 1.1.x behavior [MYFACES-3811] - Fix c:forEach behavior once for all [MYFACES-3812] - Cleanup Facelets Initialization Code and decouple facelets taglibrary config parsing [MYFACES-3813] - Cleanup org.apache.myfaces.config.impl.digester.elements package [MYFACES-3814] - Allow ServiceProviderFinder to be initialized at startup [MYFACES-3818] - Unify behavior of composite component renderer [MYFACES-3822] - General cleanup and remove unused web config params [MYFACES-3826] - Add junit test case for MyFaces and CDI [MYFACES-3827] - Replace .xsd with the ones from geronimo or written from scratch regards, Leonardo Uribe
[core] What's new in MyFaces 2.2
Hi For the people who want to know quickly what's new in MyFaces 2.2, I have written a summary of the new features here: http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html regards, Leonardo Uribe
Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest
Hi Howard I think it should work with: org.apache.myfaces.application.ResourceHandlerImpl.level = OFF regards, Leonardo 2014/1/7 Howard W. Smith, Jr. smithh032...@gmail.com: Leonardo, On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com wrote: The exception was added in the log on: https://issues.apache.org/jira/browse/MYFACES-3736 I have checked it and there is no evidence of an error from MyFaces side. Maybe we can do something to hide the exception, printing it only if Level.FINE is set. In the meanwhile, what is the best way to prevent this exception from appearing in my (tomee+) log file? can i disable it via logging.properties via the following? org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING
Re: [Tomahawk] New Release
Hi With the introduction on JSF 2.2, over the last year all efforts of MyFaces committers has been put on get a release of 2.2.0 branch, which is relatively close, but it has taken a lot of effort to get it done. The hope is after 2.2.0 the community will focus on other MyFaces projects, including MyFaces Tomahawk. Since this is an open source project, the evolution of the project depends on the contributions and interests of the members of the comunity, so any contribution on this regard is most welcome. regards, Leonardo Uribe 2013/12/18 andreas.schm...@hella.com andreas.schm...@hella.com Hello, I'm using myFaces in combination with tomahawk for a while. I wonder if there are any plans to release a new version of tomahawk. The latest release is - I think - over one year old and even this release does not contain any interessting new components that did not exist in the version for myfaces 1.2/1.2. Best regards Andreas -- View this message in context: http://myfaces.10567.n7.nabble.com/Tomahawk-New-Release-tp116784.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest
Hi Thanks to provide the link of the discussion in tomcat list. The exception was added in the log on: https://issues.apache.org/jira/browse/MYFACES-3736 I have checked it and there is no evidence of an error from MyFaces side. Maybe we can do something to hide the exception, printing it only if Level.FINE is set. regards, Leonardo Uribe 2013/11/11 Howard W. Smith, Jr. smithh032...@gmail.com FYI, On Sun, Nov 10, 2013 at 8:29 AM, Howard W. Smith, Jr. smithh032...@gmail.com wrote: more on this topic... Discussed on the tomcat list: Avoiding/Handling SocketTimeoutException(s) when web application serving resources to mobile clients[1] [1] http://tomcat.10.x6.nabble.com/Avoiding-Handling-SocketTimeoutException-s-when-web-application-serving-resources-to-mobile-clients-td5007700.html
Re: Performance params
Hi Kito 2013/10/31 Kito Mann kito.m...@virtua.com Hello everyone, I have a couple of questions about performance parameters: · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL How significant is the performance improvement for a Facelet page if this is turned off? This param avoids execute JSF 1.0 EL code, and disable jsp vdl, so EL expressions runs faster. The effect in performance is small but noticeable. · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED If I understand this correctly, this is only useful after a specific user has already reached the maximum number of views stored in the session, or am I missing something? This flag enables ids storage at facelet handler level. The effect is it increase the size of the compiled facelet in memory (because all generated ids for the compiled facelet are stored in that level) but it gives a significant performance improvement in both memory and speed. In 2.1.x/2.0.x it is disabled by default, but in 2.2.x the idea is enable it by default, because there are no side effects, and the current code has been well tested. regards, Leonardo Uribe ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://whttp://blogs.jsfcentral.com/JSFNewscast/ ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
[ANNOUNCE] MyFaces Test v1.0.5 Release
The Apache MyFaces team is pleased to announce the release of MyFaces Test 1.0.5. The Myfaces Test Framework provides mock object libraries, plus base classes for creating your own JUnit TestCases for JSF. For more information please see: http://myfaces.apache.org/test MyFaces Core is available in the central Maven repository under Group ID org.apache.myfaces.test. Release Notes - MyFaces Test - Version 1.0.5 Task [MYFACESTEST-63] - Add JSF 2.2 branch for MyFaces Test regards, Leonardo Uribe