myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: Myfaces Portlet does not work when a bean is stored in Requestscope...
Date Mon, 21 Apr 2008 23:14:34 GMT
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.


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 []
> 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 []
>>> 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 []
>>>> 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 *****************
>>>>> 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***

View raw message