Just forwarding the message from user group. -----Original Message----- From: souravm [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 5:00 PM To: MyFaces Discussion Subject: RE: Myfaces Portlet does not work when a bean is stored in Requestscope...
JBoss Portal Server works fine with JSF 1.2. The problem starts when I add the portlet-bridge-api-1.0.0-alpha-2.jar and portlet-bridge-impl-1.0.0-alpha-2.jar. It gives error while parsing the faces-config.xml file in Manifest folder of portlet-bridge-impl-1.0.0-alpha-2.jar. It says Parse Error at line 20 column 14: Document is invalid: no grammar found. Regards, Sourav -----Original Message----- From: Scott O'Bryan [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 4:15 PM To: MyFaces Discussion Subject: Re: Myfaces Portlet does not work when a bean is stored in Requestscope... I would be surprised if JBoss didn't have JSF built in. Since the RI is under development, there is no real good documentation. On the wiki I have a page which outlines getting Pluto installed in Tomcat6, presumably you could use the RI or MyFaces with that. Scott souravm wrote: > Hi Scott, > > Thanks for the list. > > Is there any good documentation available anywhere to help starting with My > faces JSF 1.2 and the Portlet Bridge ? > > I was trying to experiment with them. But at a first step itself I'm getting > problem once we put the respective jars in the jboss server. The server is > not starting up. > > Regards, > Sourav > > -----Original Message----- > From: Scott O'Bryan [mailto:[EMAIL PROTECTED] > Sent: Monday, April 21, 2008 2:45 PM > To: MyFaces Discussion > Subject: Re: Myfaces Portlet does not work when a bean is stored in > Requestscope... > > A quick list of items that will be addressed as part of 301 in JSF 1.2 > over other bridges are: > > 1. Better thought through request scope > 2. Extendible GenericFacesPortlet allowing custom behavior and mixture > of portlet/jsf generated content while still being able to use the bridge > 3. Much better thought out implementation of the ExternalContext - The > spec amends what is in JSF 1.2 where appropriate. > 4. EL Resolvers for portlet specific objects > 5. Support for "Bridge Optional" deployments where if you have an > application that works both as a portlet AND a servlet, the bridge jars > are only needed at compile time > 6. Explicit support for @PreDestroy and @PostCreate annotations which > are not supported with in JSR-168 > 7. Support for JSR-286 eventing, and resource requests that can be used > to open up AJAX. > 8. Support for *inline* content without the verbatim tag. This is a 1.2 > feature that didn't work when run from most bridges unless they were > integrated into the JSF implementation. > . > And many many more features. :) > > Scott > > Scott O'Bryan wrote: > >> souravm wrote: >> >>> Hi Scott, >>> >>> Thanks again for clearing some of the basic points. >>> >>> For the better future reference purpose here I try to summarize our >>> discussion/debate points. >>> >>> 1. Issue # 1 - How to handle initial Portlet request which has >>> request parameters. >>> >>> Yes I do agree with you that " Portals, according to Portlet >>> 1.0 spec make an initial call to a portlet through a render >>> request.". In the same context, I am also pretty much ok to go by >>> your statement " you should do as little in your render request as >>> you can, but no less ". >>> >>> However, if this is the model to be followed, it is an absolute need >>> that the original http request parameters should be made available in >>> Render request. Only then a specific application context can utilize >>> this model efficiently and decide, given a situation, what is the >>> minimal processing has to be done in the initial render request. >>> >>> >> Actually this is not the case. At least not as far as the Portal >> people I've talked to are concerned. For a given render request, any >> parameters added to that render url WILL be available to the render >> request. This means that if, in your example, you created a >> RenderRequest instead of an action, your parameter would be >> available. Portals rely on the action adding their own render >> parameters in an action request via the ActionResponse. >> >>> Even, if I revisit the thought process I went through to address my >>> specific scenario, it is the unavailability of original request >>> parameter in Render request for which I'm trying to do a work around. >>> a) JBoss Portal Server by default always sends a Render Request (as >>> it is in Portal spec) as initial call to a Portlet. But the original >>> request parameters are not available in Render request. So the bridge >>> did not work automatically. >>> >>> >> They should be... Any parameters added to the RenderURL should be >> available to the rest of the render request. Initially portals don't >> have any, that's true, but if you have a render url with some >> parameters on it, they will be available. >> >>> b) Hence, I decided to use Action Request as initial call (JBoss >>> Portal server gives me a way to achieve that). >>> c) Now, since MyFacesGenericPortlet, for the initial call does not >>> execute other phases of JSF except render phase (which is, I accept >>> that, based on Portlet spec), calling Action Request does not solve >>> my issue. >>> d) So finally, as you suggested, I need to extend the processAction() >>> method of MyFacesGenericPortlet, to add some code which can store the >>> map of original http request parameter and the same can be accessed >>> in Render Request. >>> >>> It is good that, now pretty much everyone agrees that Request >>> Attribute needs to be preserved. But, in my view, ideally it should >>> not be part of JSR 301. Rather it should be part of next Portal spec. >>> In that case, there won't be any need at all for supporting Action >>> Request as initial Portlet call. This will solve the root problem. >>> However, surely for the time being supporting Action Request at >>> initial Portlet call in JSR 301 would surely make JSF-Portlet >>> people's life easier. >>> >>> >>> >> This won't happen because it's against the design they used for >> portals and DOES NOT work with the eventing model. Seriously I would >> give up on it because the industry as a whole seems to be stacked up >> against you on this one. :) In short, parameters added to a >> RenderURL will be available during render. Parameters added during >> Event or Action requests will not be, you'll have to explicitly set >> them on the response. For what it's worth, nothing is stopping you >> from doing this yourself. >> >>> 2. Issue # 2 - In portal environment, persistence of managed bean, >>> which is defined as to be in request scope, in current Action->Render >>> sequence. >>> >>> I see your point that the managed beans in request scope need to be >>> stored not only in current Action->Render sequence but also for >>> future direct Render Request for the Portlet. >>> >>> Also I understand that, currently neither JSF spec nor Portal spec >>> dictates that whose responsibility is ensure this requirement. >>> >>> In this context, my 2 cents would be - >>> a) Probably JSR 301 is the right place to enforce it, as this is >>> about JSF portlets. >>> b) I agree with you that given this overall requirement " most >>> efficient use on this is for the request attributes to follow the >>> same lifecycle as the render parameters unless they are excluded. " >>> >>> >> 301 enforces that request attributes are preserved between action and >> render. It's unfortunate that JSR-168 did not allow this to be >> consistent at the container level which is why we decided the bridge >> should make it consistent so that all JSF applications could depend on >> the same behavior. >> >>> To answer your question about moving to JSF 2.0, currently the >>> decision is to stick to JSF 1.1 (with facelets for templating) till >>> the JSF 2.0 gets matured enough to use in a production scenario. Can >>> you please let me know any feature of JSF 2.0 which can resolve above >>> problems out of the box ? >>> >>> >> Sorry, the JSR-301 bridge has 2 specs right now. One for Portlet 1.0 >> and JSF 1.2 and the other for Portlet 2.0 and JSF 1.2. JSF 2.0 will >> be covered by future specs but should address some of the wierdness >> that was present in JSF 1.2 because the portal scenarios were not >> properly explored. >> >> The JSR-301 Spec lead is on the JSF 2.0 Expert Group so he's ensuring >> some of the insanity won't be there in the next release... :) That >> said though, upgrading to JSF 1.2 would allow you to use the new >> bridge. It's been out for a while and is pretty stable, the only >> issue is that you must use a J2EE 5 container. >> >>> However, I'll surely go through the JSR 301 spec and let me know my >>> comments. >>> >>> >> Very cool, that would be very helpful. There is a public draft for >> the Portlet 1.0 bridge. You might also want to look through JSR-286 >> (Portlet 2.0) spec to see what the new portlet spec is going to look >> like. >> >> Scott >> >>> Regards, >>> Sourav >>> >>> -----Original Message----- >>> From: Scott O'Bryan [mailto:[EMAIL PROTECTED] >>> Sent: Friday, April 18, 2008 3:57 PM >>> To: MyFaces Discussion >>> Subject: Re: Myfaces Portlet does not work when a bean is stored in >>> Requestscope... >>> >>> Eeks I wish these would have been seperate, this is going to be a long >>> response and not be as easily referenceable in the archives. >>> >>> souravm wrote: >>> >>> >>>> Hi Scott, >>>> >>>> Thanks for the detailed answer/explanation. They were really helpful >>>> to verify my understanding and also enriching the same. >>>> >>>> My consolidated response to your last 2 mails are embedded below. >>>> >>>> Regards, >>>> Sourav >>>> >>>> -----Original Message----- >>>> From: Scott O'Bryan [mailto:[EMAIL PROTECTED] >>>> Sent: Friday, April 18, 2008 12:27 PM >>>> To: MyFaces Discussion >>>> Subject: Re: Myfaces Portlet does not work when a bean is stored in >>>> Requestscope ... >>>> >>>> Souravm, >>>> >>>> Just a clairification, the request bean you have, is it not getting >>>> preserved between a single Action->Render or is it just not getting >>>> preserved in subsequent renders? >>>> >>>> <Sourav> >>>> >>>> It does not get preserved in single Action->Render. >>>> >>>> I'm not sure >>>> - Whether this should be responsibility of the Portal server to >>>> preserve the bean within the same request scope when the bean is >>>> declared to be of request scope. >>>> - Or it is responsibility of the bridge >>>> >>>> >>>> >>> Currently is it nobodies responsibility. I would certainly be >>> interested in enforcing consistency here at the bridge level. All I'm >>> saying is that in JSF, this isn't defined at all. In Portlet 1.0 it's >>> not defined either. So today, it works as it works. >>> >>> >>>> If it is the responsibility of the bridge, then my take is the root >>>> cause of this problem again goes back the issue#1 (replicating >>>> parameters/attributes from ActionRequest to RenderRequest). >>>> >>>> >>>> >>> Your first issue and this one are two COMPLETLY different things.. >>> Attributes are attributes and parameters are parameters. Why? >>> Request attributes in a portal env last though the current request while >>> request parameters last through the current request and subsequent >>> non-direct render requests. >>> >>> >>>> The entire JSF lifecycle execution (except render) happens within >>>> processAction() method which runs with the ActionRequest. So the >>>> bean creation, execution of bean's methods (which in turn populate >>>> the result to be displayed in the resultant response page created in >>>> render phase) also happen within this scope. So if the bean in its >>>> latest state needs to be stored and used in the render phase the >>>> bean has to be stored either in session (which works fine in case of >>>> session scoped bean) or it has to be explicitly set in RenderRequest. >>>> >>>> >>>> >>> This is totally incorrect actually. First off, there is nothing in JSF >>> which says the Lifecycle.execute has to happen during an action >>> request. Quite the contrary it CAN'T. Portals, according to Portlet >>> 1.0 spec make an initial call to a portlet through a render request. >>> This means that, at the very least, the initial call into the execute >>> must be a render request. When you start adding usecases for Portlet >>> 2.0, you cannot tie specific pieces of a lifecycle to specific lifecycle >>> phases. That said, I don't disagree that Request Attributes should be >>> preserved. That's how it was spec'd in JSR-301 because pretty much >>> everyone agrees with you. Pre-JSR-301 beidges did not address this >>> usecase though. It was not a requirement of JSF and the spec simply >>> says that the maps reflect what is currently stored on the request. >>> >>> As such, if you take an attribute, store it on the native Request >>> object, and then in the render try to get it, you'll find your portal is >>> not preseving that attribute. >>> >>> >>>> </Sourav> >>>> >>>> >>>> >>> >>>> The first issue, in bridges before JSR-301 is actually a portal issue. >>>> The JSR specification does not say whether request attributes set in >>>> the >>>> action request have to be available in the render request. IMO, if >>>> they >>>> are not, request attributes are basically pointless. Pre-JSR 301 >>>> bridges were ignorant of this fact and just did what the portal did. >>>> The JSR-301 bridge DOES define this behavior and I believe he have >>>> special code to handle these issues. This code is NOT in the MyFaces >>>> 1.1 bridge. >>>> >>>> <Sourav> >>>> >>>> I see your point. >>>> >>>> However, going back to the comment you made in last mail (whether >>>> this is a valid usecase or not, or should this scenario has to be >>>> handled through Render URL), I don't think using a RenderURL is a >>>> right solution. This is because following reasons - >>>> >>>> a) RenderURLs are to be directly called only when there is no >>>> processing needs to be done for a Portlet, only the previous view >>>> has to be rendered. In my understanding, this is to be used >>>> especially for the pages with multiple portlets. This ensures that >>>> in case one Portlet sends an ActionRequest, all other portlets in >>>> the same page does not need to go through the action processing for >>>> the previous request (instead they can just repeat the render phase >>>> of Portlet Lifecycle with the result from previous action). >>>> >>>> >>>> >>> You are partially correct. ProcessAction is designed to be used in >>> response to expensive processing operations which are usually caused by >>> form submissions. Portal developers realized that a person will only >>> ever interact with one portlet at a time and that, when a person does >>> interact with a portlet, they have access to things (like the request >>> input stream), that other portlets do not. >>> >>> Where you are wrong is that this HAS to be the case. Indeed during the >>> initial render of a portlet (which is always a render request) this is >>> NOT the case, because some processing has to be done. The correct way >>> to think about it is that you should do as little in your render request >>> as you can, but no less. >>> >>> So why do I think the Render URL is appropriate here? Let's say you had >>> a normal (non-JBOSS) search portlet. In order to execute it, you would >>> need an initial screen (which could absolutely do some processing). If >>> this initial screen was a JSF application, JSF would handle all the >>> binding and assignment to the backing beans and everything would work. >>> >>> >>>> b) Secondly, not sure how valid is the assumption that the first >>>> request to a Portlet will always be Render Request. Even during >>>> first time bringing up the portlet in a page there may be need of >>>> doing some processing based on the Portlet Preference which ideally >>>> should be handled in processAction() phase of Portlet lifecycle. So >>>> ideally this assumption should be relooked at.\ >>>> >>>> >>>> >>> Again, according to the Portlet 1.0 specification, this CANNOT happen. >>> The initial request in a portlet is ALWAYS a render request. It's >>> spec'd that way. Apparently JBoss has added some extensions to change >>> that, but it does not fit with JSR-168. >>> >>> >>>> I surely feel this usecase should be supported (standard >>>> struts-portlet bridges support it). I'll really appreciate if you >>>> can discuss this in next JSR 301 meeting. >>>> >>>> >>>> >>> I will, I'll get it added to the agenda.. >>> >>> >>>> </Sourav> >>>> >>>> As for the second issue, this is also something that is now handled by >>>> JSR-301, but the original attempt at JSF to define a bridge did NOT >>>> make >>>> this a requirement. In order to maintain compatibility with existing >>>> applications, the 301 bridge will preserve request attributes on >>>> subsequent "non-direct" render requests, but we also had to add a >>>> way to >>>> disable this functionality for beans that did not expect to be >>>> preserved. >>>> >>>> <Sourav> >>>> >>>> I've not really tested preserving the request for subsequent >>>> non-direct render request. As I mentioned above, I found problem >>>> even in storing the same bean within the single Action->Render >>>> sequence. >>>> >>>> However, my view is, if request parameters (in a managed bean) needs >>>> to be stored for subsequent render requests, it crosses the boundary >>>> of a single http request. Then the managed bean has to be scoped at >>>> session level. >>>> >>>> </Sourav> >>>> >>>> >>>> >>> Yeah, I know. This went back and forth as well. However, with JSF this >>> doesn't make sense. Let's say you have 2 JSF portlets. Portlet #1 has >>> a search box. You type in a value into the search box and JSF stores >>> the value into a request scoped bean and displays the results. You then >>> interact with another portlet. When your page refreshes, the item you >>> were searching for is no longer there. We've gone though quite a few >>> iterations on this and the most efficient use on this is for the request >>> attributes to follow the same lifecycle as the render parameters unless >>> they are excluded. The problem with storing everything on the session >>> is that it never goes away and this will eat up tons of memory. If your >>> application explicitly handled this storing and removing of objects, >>> that's one thing. But JSF does not allow you to easily remove a managed >>> bean from a scope. >>> >>> >>>> For issue #1, I think it would probably be appropriate to add some code >>>> to fix this. What it would entail is storing the RequestMap in a >>>> global >>>> map with a key that you would set as a render parameter. You'll >>>> need to >>>> be careful to clean up anything that might "leak". >>>> >>>> <Sourav> >>>> >>>> I agree with you on this. I'm planning to create this map in >>>> actionProcess() method in case the VIEW_ID request parameter is null >>>> (the VIEW_ID null is the flag to identify that it is a non-JSF >>>> action request). >>>> >>>> </Sourav> >>>> >>>> For issue #2, existing portlet applications in the 1.1 space DEPEND on >>>> this behavior. Changing it would break those applications. We >>>> chose to >>>> break it for JSR-301 because we though it more appropriate to preserve >>>> these parameters, but we added several mechanisms (one annotation based >>>> and one FacesConfig based) to allow these attributes to be easily >>>> excluded. >>>> >>>> <Sourav> >>>> >>>> I see your point. Hope JSR 301 and JSR 286 together can bring more >>>> predictable and intuitive behavior for Portal-JSF combination. >>>> >>>> </Sourav> >>>> >>>> >>>> >>> Well it's shaping up to be interesting. More predictable, I doubt it. >>> What 286 will do is add a bunch of functionality, like the ability to >>> support AJAX in a standardized fashion. >>> >>> Is there any reason you can't move to JSF 1.2? I would be very >>> interested in your opinions of the JSR-301 bridge which should run on >>> Portlet 1.0 and JSF1.2 just fine. The spec's are not yet final and so >>> there is still time to influence some of the usecases or, at the very >>> least, get your head around what will be the Java standard soon. >>> >>> In the mean time, I'll ask the EG if we need to support an initial >>> request being an action request. I know we've got some JBOSS guys on >>> the Expert Group so we may be able to get them to comment. For now >>> though, try generating a render url and I think you'll find that the >>> bridge will let it work. >>> >>> >>>> Hope that helps, >>>> Scott >>>> >>>> souravm wrote: >>>> >>>> >>>> >>>>> Hi All, >>>>> >>>>> I have a simple JSF application exposed as Portlet (in JBoss Portal >>>>> Server 2.6.4) using MyFacesGenericPortlet. The JSF application has >>>>> a managed bean with Request scope. >>>>> >>>>> The application works perfectly when it is run outside Portal >>>>> environment. >>>>> >>>>> But within Portal environment it does not work as the Manages Bean, >>>>> though gets initiated and do all the processing properly during the >>>>> initial lifecycle phases, during the render phase it further gets >>>>> initiated and the previous instance gets lost. >>>>> >>>>> The same works perfectly fine in Portal environment when the >>>>> Managed Bean is declared in session scope. >>>>> >>>>> Not sure whether this is the problem of MyFacesGenericPortlet or >>>>> the Portal Server where it is running. Or is it by design ? >>>>> >>>>> Any insight/viewpoint on this would be highly appreciated. >>>>> >>>>> Regards, >>>>> Sourav >>>>> >>>>> **************** CAUTION - Disclaimer ***************** >>>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION >>>>> intended solely for the use of the addressee(s). If you are not the >>>>> intended recipient, please notify the sender by e-mail and delete >>>>> the original message. Further, you are not to copy, disclose, or >>>>> distribute this e-mail or its contents to any other person and any >>>>> such actions are unlawful. This e-mail may contain viruses. Infosys >>>>> has taken every reasonable precaution to minimize this risk, but is >>>>> not liable for any damage you may sustain as a result of any virus >>>>> in this e-mail. You should carry out your own virus checks before >>>>> opening the e-mail or attachment. Infosys reserves the right to >>>>> monitor and review the content of all messages sent to or from this >>>>> e-mail address. Messages sent to or from this e-mail address may be >>>>> stored on the Infosys e-mail system. >>>>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>>>> >>>>> >>>>> >>>>> >>> > >
