Re: Myfaces Portlet does not work when a bean is stored in Requestscope...

[Scott O'Bryan <da...@gmail.com>]

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:darkarena@gmail.com]
> 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:darkarena@gmail.com]
>> 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***
>>>
>>>
>>>       
>>     
>
>   

RE: Myfaces Portlet does not work when a bean is stored in Requestscope...

[souravm <SO...@infosys.com>]

Ok.

I'm not currently in dev list. Let me add myself there and let you know.

Regards,
Sourav


-----Original Message-----
From: Scott O'Bryan [mailto:darkarena@gmail.com]
Sent: Monday, April 21, 2008 5:05 PM
To: MyFaces Discussion
Subject: Re: Myfaces Portlet does not work when a bean is stored in Requestscope...

Hey Souravm, are you on the dev list?  We should probably continue this
there.

Scott

souravm wrote:
> 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:darkarena@gmail.com]
> 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:darkarena@gmail.com]
>> 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:darkarena@gmail.com]
>>>> 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:darkarena@gmail.com]
>>>>> 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***
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>
>

Re: Myfaces Portlet does not work when a bean is stored in Requestscope...

[Scott O'Bryan <da...@gmail.com>]

Hey Souravm, are you on the dev list?  We should probably continue this 
there.

Scott

souravm wrote:
> 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:darkarena@gmail.com]
> 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:darkarena@gmail.com]
>> 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:darkarena@gmail.com]
>>>> 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:darkarena@gmail.com]
>>>>> 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***
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>     
>
>   

RE: Myfaces Portlet does not work when a bean is stored in Requestscope...

[souravm <SO...@infosys.com>]

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:darkarena@gmail.com]
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:darkarena@gmail.com]
> 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:darkarena@gmail.com]
>>> 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:darkarena@gmail.com]
>>>> 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***
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>

Re: Myfaces Portlet does not work when a bean is stored in Requestscope...

[Scott O'Bryan <da...@gmail.com>]

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:darkarena@gmail.com]
> 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:darkarena@gmail.com]
>>> 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:darkarena@gmail.com]
>>>> 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***
>>>>>
>>>>>
>>>>>
>>>>>           
>>>       
>
>   

RE: Myfaces Portlet does not work when a bean is stored in Requestscope...

[souravm <SO...@infosys.com>]

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:darkarena@gmail.com]
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:darkarena@gmail.com]
>> 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:darkarena@gmail.com]
>>> 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***
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: Myfaces Portlet does not work when a bean is stored in Requestscope...

[Scott O'Bryan <da...@gmail.com>]

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:darkarena@gmail.com]
>> 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:darkarena@gmail.com]
>>> 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***
>>>>
>>>>
>>>>       
>>>     
>>
>>   
>