Hi Really I only did a "proof of concept" prototype, fixing the problems already described and then check its performance against normal jsf. It is not a fully functional prototype and involved some changes in myfaces core internals.
For now my intention in this topic is give some ideas about what can we do. For the next release, the efforts are focused on improve myfaces algorithm. Almost all the code has been already committed. Maybe after next release I'll check stateless jsf again and propose something in MYFACES-3465. regards, Leonardo 2012/3/14 Thomas Andraschko <[email protected]>: > Hi, > > thanks! > > AFAICS you already changed code. Did you also solved this issues? Maybe you > could share your changes. > > Regards, > > > Thomas > > 2012/3/14 Leonardo Uribe <[email protected]> >> >> Hi >> >> In theory there exists 2 ids: the viewId without resolve, and the >> logical viewId. The first one is the one extracted from request path, >> and usually contains the suffix mapping (for example /home.jsf) . The >> logical is the one that points to the real resouce, for example >> /home.xhtml or /home.jspx or /home.xml). This is an example extracted >> from my experiments playing with stateless jsf: >> >> public class StatelessViewHandler extends ViewHandlerWrapper >> { >> >> @Override >> public UIViewRoot restoreView(FacesContext context, String viewId) >> { >> InitialViewCache ivch = InitialViewCache.getInstance(context); >> ViewHandler viewHandler = >> context.getApplication().getViewHandler(); >> String logicalViewId = viewHandler.deriveLogicalViewId(context, >> viewId); >> >> if (ivch.isMarkedAsStateless(rawViewId)) >> { >> >> >> The idea is be careful an use always the logical viewId, and when you >> are not sure call viewHandler.deriveLogicalViewId(context, viewId) . >> >> regards, >> >> Leonardo Uribe >> >> 2012/3/14 Thomas Andraschko <[email protected]>: >> > Hi Leonardo, >> > >> > how can i get the viewId/deriveLogicalViewId in initView()? >> > Maybe i can change this stuff the next weeks. >> > >> > Thanks, >> > Thomas >> > >> > >> > 2012/3/14 Leonardo Uribe <[email protected]> >> >> >> >> Hi >> >> >> >> 2012/3/14 PEREZ ALCAIDE JESUS <[email protected]>: >> >> > Hello, >> >> > >> >> > >> >> > >> >> > I’m creating a custom ViewHandler in order to cache the component >> >> > tree >> >> > whenever is possible. I’m following the idea of “stateless JSF” to >> >> > improve >> >> > performance. >> >> > >> >> >> >> Ok. Please be sure to read the latest discussion about this topic: >> >> >> >> >> >> >> >> http://markmail.org/message/24sbs2ltnrql7swz?q=[core]+discussion+about+stateless+jsf+implementation >> >> >> >> > >> >> > >> >> > My question is about >> >> > DefaultFaceletsStateManagementStrategy.restoreView() >> >> > method. In this method, you are calling >> >> > ViewMetadata.createMetadataView() >> >> > which ends up calling ViewHandler.createView to create the >> >> > UIViewRoot >> >> > used >> >> > for metadata and a ViewMetadataFacelet to populate it. >> >> > >> >> > >> >> > >> >> > But this UIViewRoot (created for metadata) is used later to build the >> >> > ‘real’ >> >> > view. Why? >> >> > >> >> >> >> That is for performance reasons. Suppose a request is received with >> >> some >> >> query params. To process them, it is only necessary to build the >> >> metadata >> >> and then if a navigation occur by some condition, the new view can be >> >> build, preventing the overhead associated with build the first view. >> >> >> >> > I think that a new UIViewRoot should be created for the real view, >> >> > because >> >> > metadata-view and real-view use different Facelets to populate the >> >> > view. >> >> > >> >> > >> >> > >> >> > Also, in the method >> >> > DefaultFaceletsStateManagementStrategy.restoreView() >> >> > you >> >> > are calling the static method >> >> > ViewMetadata.getViewParameters(UIViewRoot) >> >> > on >> >> > an instance of ViewMetadata (I think this should be fixed) and the >> >> > Collection of UIViewParameters returned is not processed. >> >> > >> >> > >> >> >> >> That's by JSF 2.0 spec. >> >> >> >> > >> >> > I wonder if ViewMetadata should be used in this method. I cannot see >> >> > any >> >> > processing related to metadata happening here. >> >> > >> >> > >> >> >> >> It should be, because if we don't Partial State Saving algorithm will >> >> break. The >> >> view should be build on restoreView just like the first time + update >> >> the "delta" >> >> information. >> >> >> >> > >> >> > Hope you have understood me. >> >> > >> >> > >> >> >> >> Yes, from my side, I can read the mail without problem. The idea >> >> proposed >> >> in "stateless JSF" is feasible, but it requires some changes like: >> >> >> >> - Use ConcurrentHashMap/ConcurrentLRUCache instead synchronized blocks. >> >> - Use buildView instead clone the view to generate a new one. >> >> - Use a combination of viewId/deriveLogicalViewId() >> >> >> >> Suggestions and contributions are welcome. >> >> >> >> regards, >> >> >> >> Leonardo Uribe >> >> >> >> > >> >> > >> >> > >> >> > Un saludo, >> >> > >> >> > >> >> > >> >> > Jesús Pérez Alcaide >> >> > >> >> > Lab. Banksphere - Runtime >> >> > >> >> > Tlf: 91 470 5223 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > *********************AVISO LEGAL ********************** >> >> > Este mensaje es privado y confidencial y solamente para la persona a >> >> > la >> >> > que >> >> > va dirigido. Si usted ha recibido este mensaje por error, no debe >> >> > revelar, >> >> > copiar, distribuir o usarlo en ningún sentido. Le rogamos lo >> >> > comunique >> >> > al >> >> > remitente y borre dicho mensaje y cualquier documento adjunto que >> >> > pudiera >> >> > contener. No hay renuncia a la confidencialidad ni a ningún >> >> > privilegio >> >> > por >> >> > causa de transmisión errónea o mal funcionamiento. >> >> > Cualquier opinión expresada en este mensaje pertenece únicamente al >> >> > autor >> >> > remitente, y no representa necesariamente la opinión de ISBAN, a no >> >> > ser >> >> > que >> >> > expresamente se diga y el remitente esté autorizado para hacerlo. >> >> > Los correos electrónicos no son seguros, no garantizan la >> >> > confidencialidad >> >> > ni la correcta recepción de los mismos, dado que pueden ser >> >> > interceptados, >> >> > manipulados, destruidos, llegar con demora o incompletos, o con >> >> > virus. >> >> > ISBAN >> >> > no se hace responsable de los cambios, alteraciones, errores u >> >> > omisiones >> >> > que >> >> > pudieran hacerse al mensaje una vez enviado. >> >> > Este mensaje sólo tiene una finalidad de información, y no debe >> >> > interpretarse como una oferta de venta o de compra de valores ni de >> >> > instrumentos financieros relacionados. >> >> > >> >> > **********************DISCLAIMER***************** >> >> > This message is private and confidential and it is intended >> >> > exclusively >> >> > for >> >> > the addressee. If you receive this message by mistake, you should not >> >> > disseminate, distribute or copy this e-mail. Please inform the sender >> >> > and >> >> > delete the message and attachments from your system. No >> >> > confidentiality >> >> > nor >> >> > any privilege regarding the information is waived or lost by any >> >> > mistransmission or malfunction. >> >> > Any views or opinions contained in this message are solely those of >> >> > the >> >> > author, and do not necessarily represent those of ISBAN, unless >> >> > otherwise >> >> > specifically stated and the sender is authorized to do so. >> >> > E-mail transmission cannot be guaranteed to be secure, confidential, >> >> > or >> >> > error-free, as information could be intercepted, corrupted, lost, >> >> > destroyed, >> >> > arrive late or incomplete, or contain viruses. ISBAN does not accept >> >> > responsibility for any changes, errors or omissions in the contents >> >> > of >> >> > this >> >> > message after it has been sent. >> >> > This message is provided for informational purposes and should not be >> >> > construed as a solicitation or offer to buy or sell any securities or >> >> > related financial instruments. >> > >> > > >
