Regards,
Sourav
-----Original Message-----
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Friday, April 18, 2008 3:57 PM
To: MyFaces Discussion
Subject: Re: Myfaces Portlet does not work when a bean is stored
in
Requestscope...
Eeks I wish these would have been seperate, this is going to be a
long
response and not be as easily referenceable in the archives.
souravm wrote:
Hi Scott,
Thanks for the detailed answer/explanation. They were really
helpful
to verify my understanding and also enriching the same.
My consolidated response to your last 2 mails are embedded below.
Regards,
Sourav
-----Original Message-----
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Friday, April 18, 2008 12:27 PM
To: MyFaces Discussion
Subject: Re: Myfaces Portlet does not work when a bean is stored
in
Requestscope ...
Souravm,
Just a clairification, the request bean you have, is it not
getting
preserved between a single Action->Render or is it just not
getting
preserved in subsequent renders?
<Sourav>
It does not get preserved in single Action->Render.
I'm not sure
- Whether this should be responsibility of the Portal server to
preserve the bean within the same request scope when the bean is
declared to be of request scope.
- Or it is responsibility of the bridge
Currently is it nobodies responsibility. I would certainly be
interested in enforcing consistency here at the bridge level.
All I'm
saying is that in JSF, this isn't defined at all. In Portlet 1.0
it's
not defined either. So today, it works as it works.
If it is the responsibility of the bridge, then my take is the
root
cause of this problem again goes back the issue#1 (replicating
parameters/attributes from ActionRequest to RenderRequest).
Your first issue and this one are two COMPLETLY different things..
Attributes are attributes and parameters are parameters. Why?
Request attributes in a portal env last though the current
request while
request parameters last through the current request and subsequent
non-direct render requests.
The entire JSF lifecycle execution (except render) happens within
processAction() method which runs with the ActionRequest. So the
bean creation, execution of bean's methods (which in turn
populate
the result to be displayed in the resultant response page
created in
render phase) also happen within this scope. So if the bean in
its
latest state needs to be stored and used in the render phase the
bean has to be stored either in session (which works fine in
case of
session scoped bean) or it has to be explicitly set in
RenderRequest.
This is totally incorrect actually. First off, there is nothing
in JSF
which says the Lifecycle.execute has to happen during an action
request. Quite the contrary it CAN'T. Portals, according to
Portlet
1.0 spec make an initial call to a portlet through a render
request.
This means that, at the very least, the initial call into the
execute
must be a render request. When you start adding usecases for
Portlet
2.0, you cannot tie specific pieces of a lifecycle to specific
lifecycle
phases. That said, I don't disagree that Request Attributes
should be
preserved. That's how it was spec'd in JSR-301 because pretty
much
everyone agrees with you. Pre-JSR-301 beidges did not address
this
usecase though. It was not a requirement of JSF and the spec
simply
says that the maps reflect what is currently stored on the
request.
As such, if you take an attribute, store it on the native Request
object, and then in the render try to get it, you'll find your
portal is
not preseving that attribute.
</Sourav>
The first issue, in bridges before JSR-301 is actually a portal
issue.
The JSR specification does not say whether request attributes
set in
the
action request have to be available in the render request. IMO,
if
they
are not, request attributes are basically pointless. Pre-JSR 301
bridges were ignorant of this fact and just did what the portal
did.
The JSR-301 bridge DOES define this behavior and I believe he
have
special code to handle these issues. This code is NOT in the
MyFaces
1.1 bridge.
<Sourav>
I see your point.
However, going back to the comment you made in last mail (whether
this is a valid usecase or not, or should this scenario has to be
handled through Render URL), I don't think using a RenderURL is a
right solution. This is because following reasons -
a) RenderURLs are to be directly called only when there is no
processing needs to be done for a Portlet, only the previous view
has to be rendered. In my understanding, this is to be used
especially for the pages with multiple portlets. This ensures
that
in case one Portlet sends an ActionRequest, all other portlets in
the same page does not need to go through the action processing
for
the previous request (instead they can just repeat the render
phase
of Portlet Lifecycle with the result from previous action).
You are partially correct. ProcessAction is designed to be used
in
response to expensive processing operations which are usually
caused by
form submissions. Portal developers realized that a person will
only
ever interact with one portlet at a time and that, when a person
does
interact with a portlet, they have access to things (like the
request
input stream), that other portlets do not.
Where you are wrong is that this HAS to be the case. Indeed
during the
initial render of a portlet (which is always a render request)
this is
NOT the case, because some processing has to be done. The
correct way
to think about it is that you should do as little in your render
request
as you can, but no less.
So why do I think the Render URL is appropriate here? Let's say
you had
a normal (non-JBOSS) search portlet. In order to execute it, you
would
need an initial screen (which could absolutely do some
processing). If
this initial screen was a JSF application, JSF would handle all
the
binding and assignment to the backing beans and everything would
work.
b) Secondly, not sure how valid is the assumption that the first
request to a Portlet will always be Render Request. Even during
first time bringing up the portlet in a page there may be need of
doing some processing based on the Portlet Preference which
ideally
should be handled in processAction() phase of Portlet lifecycle.
So
ideally this assumption should be relooked at.\
Again, according to the Portlet 1.0 specification, this CANNOT
happen.
The initial request in a portlet is ALWAYS a render request. It's
spec'd that way. Apparently JBoss has added some extensions to
change
that, but it does not fit with JSR-168.
I surely feel this usecase should be supported (standard
struts-portlet bridges support it). I'll really appreciate if you
can discuss this in next JSR 301 meeting.
I will, I'll get it added to the agenda..
</Sourav>
As for the second issue, this is also something that is now
handled by
JSR-301, but the original attempt at JSF to define a bridge did
NOT
make
this a requirement. In order to maintain compatibility with
existing
applications, the 301 bridge will preserve request attributes on
subsequent "non-direct" render requests, but we also had to add a
way to
disable this functionality for beans that did not expect to be
preserved.
<Sourav>
I've not really tested preserving the request for subsequent
non-direct render request. As I mentioned above, I found problem
even in storing the same bean within the single Action->Render
sequence.
However, my view is, if request parameters (in a managed bean)
needs
to be stored for subsequent render requests, it crosses the
boundary
of a single http request. Then the managed bean has to be scoped
at
session level.
</Sourav>
Yeah, I know. This went back and forth as well. However, with
JSF this
doesn't make sense. Let's say you have 2 JSF portlets. Portlet
#1 has
a search box. You type in a value into the search box and JSF
stores
the value into a request scoped bean and displays the results.
You then
interact with another portlet. When your page refreshes, the
item you
were searching for is no longer there. We've gone though quite a
few
iterations on this and the most efficient use on this is for the
request
attributes to follow the same lifecycle as the render parameters
unless
they are excluded. The problem with storing everything on the
session
is that it never goes away and this will eat up tons of memory.
If your
application explicitly handled this storing and removing of
objects,
that's one thing. But JSF does not allow you to easily remove a
managed
bean from a scope.
For issue #1, I think it would probably be appropriate to add
some code
to fix this. What it would entail is storing the RequestMap in a
global
map with a key that you would set as a render parameter. You'll
need to
be careful to clean up anything that might "leak".
<Sourav>
I agree with you on this. I'm planning to create this map in
actionProcess() method in case the VIEW_ID request parameter is
null
(the VIEW_ID null is the flag to identify that it is a non-JSF
action request).
</Sourav>
For issue #2, existing portlet applications in the 1.1 space
DEPEND on
this behavior. Changing it would break those applications. We
chose to
break it for JSR-301 because we though it more appropriate to
preserve
these parameters, but we added several mechanisms (one
annotation based
and one FacesConfig based) to allow these attributes to be easily
excluded.
<Sourav>
I see your point. Hope JSR 301 and JSR 286 together can bring
more
predictable and intuitive behavior for Portal-JSF combination.
</Sourav>
Well it's shaping up to be interesting. More predictable, I
doubt it.
What 286 will do is add a bunch of functionality, like the
ability to
support AJAX in a standardized fashion.
Is there any reason you can't move to JSF 1.2? I would be very
interested in your opinions of the JSR-301 bridge which should
run on
Portlet 1.0 and JSF1.2 just fine. The spec's are not yet final
and so
there is still time to influence some of the usecases or, at the
very
least, get your head around what will be the Java standard soon.
In the mean time, I'll ask the EG if we need to support an initial
request being an action request. I know we've got some JBOSS
guys on
the Expert Group so we may be able to get them to comment. For
now
though, try generating a render url and I think you'll find that
the
bridge will let it work.
Hope that helps,
Scott
souravm wrote:
Hi All,
I have a simple JSF application exposed as Portlet (in JBoss
Portal
Server 2.6.4) using MyFacesGenericPortlet. The JSF application
has
a managed bean with Request scope.
The application works perfectly when it is run outside Portal
environment.
But within Portal environment it does not work as the Manages
Bean,
though gets initiated and do all the processing properly during
the
initial lifecycle phases, during the render phase it further
gets
initiated and the previous instance gets lost.
The same works perfectly fine in Portal environment when the
Managed Bean is declared in session scope.
Not sure whether this is the problem of MyFacesGenericPortlet or
the Portal Server where it is running. Or is it by design ?
Any insight/viewpoint on this would be highly appreciated.
Regards,
Sourav
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION
intended solely for the use of the addressee(s). If you are not
the
intended recipient, please notify the sender by e-mail and
delete
the original message. Further, you are not to copy, disclose, or
distribute this e-mail or its contents to any other person and
any
such actions are unlawful. This e-mail may contain viruses.
Infosys
has taken every reasonable precaution to minimize this risk,
but is
not liable for any damage you may sustain as a result of any
virus
in this e-mail. You should carry out your own virus checks
before
opening the e-mail or attachment. Infosys reserves the right to
monitor and review the content of all messages sent to or from
this
e-mail address. Messages sent to or from this e-mail address
may be
stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
