myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <darkar...@gmail.com>
Subject Re: FW: Myfaces Portlet does not work when a bean is stored in Requestscope...
Date Wed, 23 Apr 2008 21:24:56 GMT
Ohh, good point Mike.  I think he's picking this up from the faces 
config INSIDE of the bridge jars...

Scott

Michael Freedman wrote:
> Okay -- the JBoss portal must be validating the faces-config.xml file 
> included in the jar.  Anyway you can disable this?  If not you will 
> need to remove the offending stuff from the faces-config.xml file.  
> The initial lines of the file (after the comments are:
> <faces-config version="*1.2*" 
> xmlns="*http://java.sun.com/xml/ns/javaee*" 
> xmlns:bridge="*http://www.apache.org/myfaces/xml/ns/bridge/bridge-extension*">
>
> The line that is failing is the 
> "xmlns:bridge="*http://www.apache.org/myfaces/xml/ns/bridge/bridge-extension*".  
> As the xsd doesn't (yet) live here.  Merely remove it.  Also remove:
> - <#> <application-extension>
> - <#>    <bridge:excluded-attributes>
>            
> <bridge:excluded-attribute>com.sun.faces.*</bridge:excluded-attribute>
>   </bridge:excluded-attributes>
> </application-extension>
>
> Save the file back into the jar file and rerun.  You should now be fine.
>
> Note:  what you are removing is an extension recognized by the bridge 
> that tells the bridge it shouldn't include any com.sun.faces.* 
> attributes in the bridge managed request scope.  I think its okay for 
> this not to be there (won't break the bridge/faces)  however if you 
> want to be safe -- add the following to your portlet section in your 
> portlet.xml:
>         <init-param>
>             <name>javax.portlet.faces.excludedRequestAttributes</name>
>             <value>com.sun.faces.*</value>
>         </init-param>
>
> -Mike-
>
> souravm wrote:
>> Just forwarding the message from user group.
>>
>> -----Original Message-----
>> From: souravm [mailto:SOURAVM@infosys.com]
>> Sent: Monday, April 21, 2008 5:00 PM
>> To: MyFaces Discussion
>> Subject: RE: Myfaces Portlet does not work when a bean is stored in Requestscope...
>>
>> JBoss Portal Server works fine with JSF 1.2.
>>
>> The problem starts when I add the portlet-bridge-api-1.0.0-alpha-2.jar and portlet-bridge-impl-1.0.0-alpha-2.jar.
>>
>> It gives error while parsing the faces-config.xml file in Manifest folder of portlet-bridge-impl-1.0.0-alpha-2.jar.
It says Parse Error at line 20 column 14: Document is invalid: no grammar found.
>>
>> Regards,
>> Sourav
>>
>> -----Original Message-----
>> From: Scott O'Bryan [mailto: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***
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>             
>>>     
>>
>>   


Mime
View raw message