You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by souravm <SO...@infosys.com> on 2008/04/17 03:38:00 UTC
Calling a Myfaces Portlet from a non-JSF request ..
Hi All,
I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
First time I need to access this portlet from a non-JSF (jsp) page which sends a http post request with some request parameters.
The solution does not work when the request does not have any request parameter (works fine when accessed by a request with no request parameter).
When I try to read the request parameter(s) in the constructor of the managed bean they come as null.
I tried extending the processAction() method of MyFacesGenericPortlet. I read the request parameters from the ActionRequest and set them in RenderRequest using setRenderParameter (This anyway one has to do for a jsp based portlet implementation). With this approach I can read the request parameters in the constructor of the managed bean.
I would like to validate whether this is a known limitation of MyFacesGenericPortlet and the solution approach mentioned above is right one (or any other approach is recommended) ?
Any help in this regard would be highly appreciated.
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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by Scott O'Bryan <da...@gmail.com>.
Souravm, there is actually no easy answer to this. This was a huge
discussion item in the JSR-301 Expert Group as well, and we had to punt
on it. Let me start off by stating cannon from the most current JSR-301
specification...
By default a bridge DOES NOT preserve parameters from an action request
to a render request. The reasons for this are many, not the least of
which involves some oddities with how PPR might work. The main issue is
that once set, render parameters remain until the next REAL render
request. The JSR-301 Bridge DOES have a setting which would force the
bridge to save these render parameters, but this is mostly considered to
be a temporary *compatibility mode* setting.
The reason your running into this is that the bridge expects the first
call into it to be a render request. In this case, the parameters DO
make it into the render request just fine.. I would be reluctant to
change the default actions of the MyFaces 1.1 bridge, especially when
they agree with how JSR-301 currently does things in this regard.
So my question is this, does JBoss portal allow you to create a render url?
If you want me to, I can also take this up in the next JSR-301 meeting
next week and see if people think it's a usecase we need to support.
Scott
souravm wrote:
> Yes. As I don't think there is any other option available. And I wanted to validate my understanding regarding that in this thread.
>
> Here is the problem situation -
>
> 1. I cannot execute the normal JSF lifecycle.execute() as for that the ActionRequest needs to have MyFacesGenericPortlet.VIEW_ID populated as one of the request parameters with the target view jsp/xhtml.
> 2. So I need to directly go to doView(). At this point the request and response in facesConfig is changed to RenderRequest and RenderResponse. The RenderRequest doesn't content the original request parameters which were in the ActionRequest, unless those parameters are explicitly populated using request.setRenderParameters().
> 3. The renderView() will in turn call the facesRender() and which will in turn call the nonFacesRequest() (as the VIEW_ID is null)
> 4. The nonFacesRequest() method will first set the default view as the view and will eventually call the lifecycle.render()
> 5. The lifecycle.render() will initiate the bean referred in the default view page but it cannot populate the bean attributes with the original request parameters as those parameters are not available in RenderRequest (unless explicitly populated as methioned in step 2).
>
> So as a solution I thought -
>
> 1. In processAction() we can populate all request parameters of ActionRequest in RenderRequest using request.setRenderParameters().
> 2. In the constructor of the bean (which is called in step 5 mentioned above) access them from RenderRequest and populate the bean attributes.
>
> I've also thought of another approach where I can create the target bean in processAction() using the request parameters in ActionRequest and keep the bean in session. However, this solution will not be generic as one can not access the target bean names in generic way at processAction() method.
>
> Any other viewpoint/suggestion in this regard would be highly appreciated.
>
> Regards,
> Sourav
>
>
>
> ________________________________________
> From: Scott O'Bryan [darkarena@gmail.com]
> Sent: Friday, April 18, 2008 5:45 AM
> To: MyFaces Discussion
> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>
> Ahh, I see. So you're trying to reference the action parameters from
> the Render?
>
> Scott
>
> souravm wrote:
>
>> Hi Scott,
>>
>> We are doing exactly what you mentioned in the 3rd paragraph of your mail.
>>
>> Whatexactly happening in MyFacesGenericPortlet is -
>>
>> a) The Request is passed to the nonFacesRequestMethod
>> b) It executes the lifecycle.render method (so other lifecycle phases are skipped)
>>
>> Due to this the request parameters are never available in the RenderRequest.
>>
>> I think this is a design bug of MyFacesGenericPortlet. It handles the non faces request but does not handle the request parameters properly.
>>
>> Regards,
>> Sourav
>>
>>
>>
>> -----Original Message-----
>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>> Sent: Thursday, April 17, 2008 10:52 AM
>> To: MyFaces Discussion
>> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>>
>> Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
>> detail. It, of course, is dependent on JSF 1.2 (for a bunch of
>> reasons). Still, this is not really a JSF issue I don't think (unless
>> the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
>>
>> I'm not familiar with JBoss Portal's header framework, but I can only
>> assume that it's a way to put a portlet somewhere in the portal's header
>> rather then in the main content region. The issue here is that any
>> ActionUrl you create will reference the header instance unless they also
>> provide you some mechanism for a specific portlet instance.
>>
>> If they do have the latter mechanism, you basically need to either
>> "post" to the portlet you want to reflect your results (meaning it
>> needs to be on the current page already, or you will have to create a
>> new ActionUrl which references your portlet instance, append your
>> parameters to that which you need the portlet to recieve, and then do a
>> redirect with that URL. Does this make sense?
>>
>> Scott
>>
>> souravm wrote:
>>
>>
>>> Thanks Scott for your suggestion.
>>>
>>> I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
>>>
>>> Let me explain you a bit on the origin of this requirements.
>>>
>>> The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
>>>
>>> Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
>>>
>>> So that's being the case -
>>>
>>> 1. The JSF Portlet being still called within the Portal Framework with encoded URL.
>>> 2. The request is still a Post request (form submit happens from the Search Box form).
>>>
>>> Considering this situation any further suggestion is really appreciated.
>>>
>>> Regards,
>>> Sourav
>>>
>>> -----Original Message-----
>>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>>> Sent: Thursday, April 17, 2008 8:48 AM
>>> To: MyFaces Discussion
>>> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>>>
>>> One more thing, this has nothing to do with JSF. It's has to do with
>>> trying to call a portlet from outside of a Portal. :) It is possible the
>>> JBOSS portal has an off-spec proprietary way to pass parameters into a
>>> portlet, but you'll have to take it up with them.
>>>
>>> souravm wrote:
>>>
>>>
>>>
>>>> Hi All,
>>>>
>>>> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>>>>
>>>> First time I need to access this portlet from a non-JSF (jsp) page
>>>> which sends a http post request with some request parameters.
>>>>
>>>> The solution does not work when the request does not have any request
>>>> parameter (works fine when accessed by a request with no request
>>>> parameter).
>>>>
>>>> When I try to read the request parameter(s) in the constructor of the
>>>> managed bean they come as null.
>>>>
>>>> I tried extending the processAction() method of MyFacesGenericPortlet.
>>>> I read the request parameters from the ActionRequest and set them in
>>>> RenderRequest using setRenderParameter (This anyway one has to do for
>>>> a jsp based portlet implementation). With this approach I can read the
>>>> request parameters in the constructor of the managed bean.
>>>>
>>>> I would like to validate whether this is a known limitation of
>>>> MyFacesGenericPortlet and the solution approach mentioned above is
>>>> right one (or any other approach is recommended) ?
>>>>
>>>> Any help in this regard would be highly appreciated.
>>>>
>>>> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by souravm <SO...@infosys.com>.
Yes. As I don't think there is any other option available. And I wanted to validate my understanding regarding that in this thread.
Here is the problem situation -
1. I cannot execute the normal JSF lifecycle.execute() as for that the ActionRequest needs to have MyFacesGenericPortlet.VIEW_ID populated as one of the request parameters with the target view jsp/xhtml.
2. So I need to directly go to doView(). At this point the request and response in facesConfig is changed to RenderRequest and RenderResponse. The RenderRequest doesn't content the original request parameters which were in the ActionRequest, unless those parameters are explicitly populated using request.setRenderParameters().
3. The renderView() will in turn call the facesRender() and which will in turn call the nonFacesRequest() (as the VIEW_ID is null)
4. The nonFacesRequest() method will first set the default view as the view and will eventually call the lifecycle.render()
5. The lifecycle.render() will initiate the bean referred in the default view page but it cannot populate the bean attributes with the original request parameters as those parameters are not available in RenderRequest (unless explicitly populated as methioned in step 2).
So as a solution I thought -
1. In processAction() we can populate all request parameters of ActionRequest in RenderRequest using request.setRenderParameters().
2. In the constructor of the bean (which is called in step 5 mentioned above) access them from RenderRequest and populate the bean attributes.
I've also thought of another approach where I can create the target bean in processAction() using the request parameters in ActionRequest and keep the bean in session. However, this solution will not be generic as one can not access the target bean names in generic way at processAction() method.
Any other viewpoint/suggestion in this regard would be highly appreciated.
Regards,
Sourav
________________________________________
From: Scott O'Bryan [darkarena@gmail.com]
Sent: Friday, April 18, 2008 5:45 AM
To: MyFaces Discussion
Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
Ahh, I see. So you're trying to reference the action parameters from
the Render?
Scott
souravm wrote:
> Hi Scott,
>
> We are doing exactly what you mentioned in the 3rd paragraph of your mail.
>
> Whatexactly happening in MyFacesGenericPortlet is -
>
> a) The Request is passed to the nonFacesRequestMethod
> b) It executes the lifecycle.render method (so other lifecycle phases are skipped)
>
> Due to this the request parameters are never available in the RenderRequest.
>
> I think this is a design bug of MyFacesGenericPortlet. It handles the non faces request but does not handle the request parameters properly.
>
> Regards,
> Sourav
>
>
>
> -----Original Message-----
> From: Scott O'Bryan [mailto:darkarena@gmail.com]
> Sent: Thursday, April 17, 2008 10:52 AM
> To: MyFaces Discussion
> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>
> Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
> detail. It, of course, is dependent on JSF 1.2 (for a bunch of
> reasons). Still, this is not really a JSF issue I don't think (unless
> the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
>
> I'm not familiar with JBoss Portal's header framework, but I can only
> assume that it's a way to put a portlet somewhere in the portal's header
> rather then in the main content region. The issue here is that any
> ActionUrl you create will reference the header instance unless they also
> provide you some mechanism for a specific portlet instance.
>
> If they do have the latter mechanism, you basically need to either
> "post" to the portlet you want to reflect your results (meaning it
> needs to be on the current page already, or you will have to create a
> new ActionUrl which references your portlet instance, append your
> parameters to that which you need the portlet to recieve, and then do a
> redirect with that URL. Does this make sense?
>
> Scott
>
> souravm wrote:
>
>> Thanks Scott for your suggestion.
>>
>> I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
>>
>> Let me explain you a bit on the origin of this requirements.
>>
>> The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
>>
>> Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
>>
>> So that's being the case -
>>
>> 1. The JSF Portlet being still called within the Portal Framework with encoded URL.
>> 2. The request is still a Post request (form submit happens from the Search Box form).
>>
>> Considering this situation any further suggestion is really appreciated.
>>
>> Regards,
>> Sourav
>>
>> -----Original Message-----
>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>> Sent: Thursday, April 17, 2008 8:48 AM
>> To: MyFaces Discussion
>> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>>
>> One more thing, this has nothing to do with JSF. It's has to do with
>> trying to call a portlet from outside of a Portal. :) It is possible the
>> JBOSS portal has an off-spec proprietary way to pass parameters into a
>> portlet, but you'll have to take it up with them.
>>
>> souravm wrote:
>>
>>
>>> Hi All,
>>>
>>> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>>>
>>> First time I need to access this portlet from a non-JSF (jsp) page
>>> which sends a http post request with some request parameters.
>>>
>>> The solution does not work when the request does not have any request
>>> parameter (works fine when accessed by a request with no request
>>> parameter).
>>>
>>> When I try to read the request parameter(s) in the constructor of the
>>> managed bean they come as null.
>>>
>>> I tried extending the processAction() method of MyFacesGenericPortlet.
>>> I read the request parameters from the ActionRequest and set them in
>>> RenderRequest using setRenderParameter (This anyway one has to do for
>>> a jsp based portlet implementation). With this approach I can read the
>>> request parameters in the constructor of the managed bean.
>>>
>>> I would like to validate whether this is a known limitation of
>>> MyFacesGenericPortlet and the solution approach mentioned above is
>>> right one (or any other approach is recommended) ?
>>>
>>> Any help in this regard would be highly appreciated.
>>>
>>> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by Scott O'Bryan <da...@gmail.com>.
Ahh, I see. So you're trying to reference the action parameters from
the Render?
Scott
souravm wrote:
> Hi Scott,
>
> We are doing exactly what you mentioned in the 3rd paragraph of your mail.
>
> Whatexactly happening in MyFacesGenericPortlet is -
>
> a) The Request is passed to the nonFacesRequestMethod
> b) It executes the lifecycle.render method (so other lifecycle phases are skipped)
>
> Due to this the request parameters are never available in the RenderRequest.
>
> I think this is a design bug of MyFacesGenericPortlet. It handles the non faces request but does not handle the request parameters properly.
>
> Regards,
> Sourav
>
>
>
> -----Original Message-----
> From: Scott O'Bryan [mailto:darkarena@gmail.com]
> Sent: Thursday, April 17, 2008 10:52 AM
> To: MyFaces Discussion
> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>
> Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
> detail. It, of course, is dependent on JSF 1.2 (for a bunch of
> reasons). Still, this is not really a JSF issue I don't think (unless
> the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
>
> I'm not familiar with JBoss Portal's header framework, but I can only
> assume that it's a way to put a portlet somewhere in the portal's header
> rather then in the main content region. The issue here is that any
> ActionUrl you create will reference the header instance unless they also
> provide you some mechanism for a specific portlet instance.
>
> If they do have the latter mechanism, you basically need to either
> "post" to the portlet you want to reflect your results (meaning it
> needs to be on the current page already, or you will have to create a
> new ActionUrl which references your portlet instance, append your
> parameters to that which you need the portlet to recieve, and then do a
> redirect with that URL. Does this make sense?
>
> Scott
>
> souravm wrote:
>
>> Thanks Scott for your suggestion.
>>
>> I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
>>
>> Let me explain you a bit on the origin of this requirements.
>>
>> The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
>>
>> Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
>>
>> So that's being the case -
>>
>> 1. The JSF Portlet being still called within the Portal Framework with encoded URL.
>> 2. The request is still a Post request (form submit happens from the Search Box form).
>>
>> Considering this situation any further suggestion is really appreciated.
>>
>> Regards,
>> Sourav
>>
>> -----Original Message-----
>> From: Scott O'Bryan [mailto:darkarena@gmail.com]
>> Sent: Thursday, April 17, 2008 8:48 AM
>> To: MyFaces Discussion
>> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>>
>> One more thing, this has nothing to do with JSF. It's has to do with
>> trying to call a portlet from outside of a Portal. :) It is possible the
>> JBOSS portal has an off-spec proprietary way to pass parameters into a
>> portlet, but you'll have to take it up with them.
>>
>> souravm wrote:
>>
>>
>>> Hi All,
>>>
>>> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>>>
>>> First time I need to access this portlet from a non-JSF (jsp) page
>>> which sends a http post request with some request parameters.
>>>
>>> The solution does not work when the request does not have any request
>>> parameter (works fine when accessed by a request with no request
>>> parameter).
>>>
>>> When I try to read the request parameter(s) in the constructor of the
>>> managed bean they come as null.
>>>
>>> I tried extending the processAction() method of MyFacesGenericPortlet.
>>> I read the request parameters from the ActionRequest and set them in
>>> RenderRequest using setRenderParameter (This anyway one has to do for
>>> a jsp based portlet implementation). With this approach I can read the
>>> request parameters in the constructor of the managed bean.
>>>
>>> I would like to validate whether this is a known limitation of
>>> MyFacesGenericPortlet and the solution approach mentioned above is
>>> right one (or any other approach is recommended) ?
>>>
>>> Any help in this regard would be highly appreciated.
>>>
>>> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by souravm <SO...@infosys.com>.
Hi Scott,
We are doing exactly what you mentioned in the 3rd paragraph of your mail.
Whatexactly happening in MyFacesGenericPortlet is -
a) The Request is passed to the nonFacesRequestMethod
b) It executes the lifecycle.render method (so other lifecycle phases are skipped)
Due to this the request parameters are never available in the RenderRequest.
I think this is a design bug of MyFacesGenericPortlet. It handles the non faces request but does not handle the request parameters properly.
Regards,
Sourav
-----Original Message-----
From: Scott O'Bryan [mailto:darkarena@gmail.com]
Sent: Thursday, April 17, 2008 10:52 AM
To: MyFaces Discussion
Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
detail. It, of course, is dependent on JSF 1.2 (for a bunch of
reasons). Still, this is not really a JSF issue I don't think (unless
the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
I'm not familiar with JBoss Portal's header framework, but I can only
assume that it's a way to put a portlet somewhere in the portal's header
rather then in the main content region. The issue here is that any
ActionUrl you create will reference the header instance unless they also
provide you some mechanism for a specific portlet instance.
If they do have the latter mechanism, you basically need to either
"post" to the portlet you want to reflect your results (meaning it
needs to be on the current page already, or you will have to create a
new ActionUrl which references your portlet instance, append your
parameters to that which you need the portlet to recieve, and then do a
redirect with that URL. Does this make sense?
Scott
souravm wrote:
> Thanks Scott for your suggestion.
>
> I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
>
> Let me explain you a bit on the origin of this requirements.
>
> The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
>
> Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
>
> So that's being the case -
>
> 1. The JSF Portlet being still called within the Portal Framework with encoded URL.
> 2. The request is still a Post request (form submit happens from the Search Box form).
>
> Considering this situation any further suggestion is really appreciated.
>
> Regards,
> Sourav
>
> -----Original Message-----
> From: Scott O'Bryan [mailto:darkarena@gmail.com]
> Sent: Thursday, April 17, 2008 8:48 AM
> To: MyFaces Discussion
> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>
> One more thing, this has nothing to do with JSF. It's has to do with
> trying to call a portlet from outside of a Portal. :) It is possible the
> JBOSS portal has an off-spec proprietary way to pass parameters into a
> portlet, but you'll have to take it up with them.
>
> souravm wrote:
>
>> Hi All,
>>
>> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>>
>> First time I need to access this portlet from a non-JSF (jsp) page
>> which sends a http post request with some request parameters.
>>
>> The solution does not work when the request does not have any request
>> parameter (works fine when accessed by a request with no request
>> parameter).
>>
>> When I try to read the request parameter(s) in the constructor of the
>> managed bean they come as null.
>>
>> I tried extending the processAction() method of MyFacesGenericPortlet.
>> I read the request parameters from the ActionRequest and set them in
>> RenderRequest using setRenderParameter (This anyway one has to do for
>> a jsp based portlet implementation). With this approach I can read the
>> request parameters in the constructor of the managed bean.
>>
>> I would like to validate whether this is a known limitation of
>> MyFacesGenericPortlet and the solution approach mentioned above is
>> right one (or any other approach is recommended) ?
>>
>> Any help in this regard would be highly appreciated.
>>
>> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by Scott O'Bryan <da...@gmail.com>.
Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
detail. It, of course, is dependent on JSF 1.2 (for a bunch of
reasons). Still, this is not really a JSF issue I don't think (unless
the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
I'm not familiar with JBoss Portal's header framework, but I can only
assume that it's a way to put a portlet somewhere in the portal's header
rather then in the main content region. The issue here is that any
ActionUrl you create will reference the header instance unless they also
provide you some mechanism for a specific portlet instance.
If they do have the latter mechanism, you basically need to either
"post" to the portlet you want to reflect your results (meaning it
needs to be on the current page already, or you will have to create a
new ActionUrl which references your portlet instance, append your
parameters to that which you need the portlet to recieve, and then do a
redirect with that URL. Does this make sense?
Scott
souravm wrote:
> Thanks Scott for your suggestion.
>
> I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
>
> Let me explain you a bit on the origin of this requirements.
>
> The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
>
> Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
>
> So that's being the case -
>
> 1. The JSF Portlet being still called within the Portal Framework with encoded URL.
> 2. The request is still a Post request (form submit happens from the Search Box form).
>
> Considering this situation any further suggestion is really appreciated.
>
> Regards,
> Sourav
>
> -----Original Message-----
> From: Scott O'Bryan [mailto:darkarena@gmail.com]
> Sent: Thursday, April 17, 2008 8:48 AM
> To: MyFaces Discussion
> Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
>
> One more thing, this has nothing to do with JSF. It's has to do with
> trying to call a portlet from outside of a Portal. :) It is possible the
> JBOSS portal has an off-spec proprietary way to pass parameters into a
> portlet, but you'll have to take it up with them.
>
> souravm wrote:
>
>> Hi All,
>>
>> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>>
>> First time I need to access this portlet from a non-JSF (jsp) page
>> which sends a http post request with some request parameters.
>>
>> The solution does not work when the request does not have any request
>> parameter (works fine when accessed by a request with no request
>> parameter).
>>
>> When I try to read the request parameter(s) in the constructor of the
>> managed bean they come as null.
>>
>> I tried extending the processAction() method of MyFacesGenericPortlet.
>> I read the request parameters from the ActionRequest and set them in
>> RenderRequest using setRenderParameter (This anyway one has to do for
>> a jsp based portlet implementation). With this approach I can read the
>> request parameters in the constructor of the managed bean.
>>
>> I would like to validate whether this is a known limitation of
>> MyFacesGenericPortlet and the solution approach mentioned above is
>> right one (or any other approach is recommended) ?
>>
>> Any help in this regard would be highly appreciated.
>>
>> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by souravm <SO...@infosys.com>.
Thanks Scott for your suggestion.
I know I'm struggling to find a solution which involves 2 specs JSF and Portlet (most probably the 2 most complicated one today in J2EE world).
Let me explain you a bit on the origin of this requirements.
The Portal application we are developing needs to have a search box in header. That Search box needs to appear in every page at the top right corner where user will enter a search criterion. And the result of the search needs to be displayed in the main content window of the Portal
Now creating this Search Box using a Portlet does not make sense as that will make the portal layout very complicated. So we use the Jboss Portal's header framework to create this search box. And as a submission of the search request we try to initiate a portlet.
So that's being the case -
1. The JSF Portlet being still called within the Portal Framework with encoded URL.
2. The request is still a Post request (form submit happens from the Search Box form).
Considering this situation any further suggestion is really appreciated.
Regards,
Sourav
-----Original Message-----
From: Scott O'Bryan [mailto:darkarena@gmail.com]
Sent: Thursday, April 17, 2008 8:48 AM
To: MyFaces Discussion
Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
One more thing, this has nothing to do with JSF. It's has to do with
trying to call a portlet from outside of a Portal. :) It is possible the
JBOSS portal has an off-spec proprietary way to pass parameters into a
portlet, but you'll have to take it up with them.
souravm wrote:
>
> Hi All,
>
> I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>
> First time I need to access this portlet from a non-JSF (jsp) page
> which sends a http post request with some request parameters.
>
> The solution does not work when the request does not have any request
> parameter (works fine when accessed by a request with no request
> parameter).
>
> When I try to read the request parameter(s) in the constructor of the
> managed bean they come as null.
>
> I tried extending the processAction() method of MyFacesGenericPortlet.
> I read the request parameters from the ActionRequest and set them in
> RenderRequest using setRenderParameter (This anyway one has to do for
> a jsp based portlet implementation). With this approach I can read the
> request parameters in the constructor of the managed bean.
>
> I would like to validate whether this is a known limitation of
> MyFacesGenericPortlet and the solution approach mentioned above is
> right one (or any other approach is recommended) ?
>
> Any help in this regard would be highly appreciated.
>
> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by Scott O'Bryan <da...@gmail.com>.
One more thing, this has nothing to do with JSF. It's has to do with
trying to call a portlet from outside of a Portal. :) It is possible the
JBOSS portal has an off-spec proprietary way to pass parameters into a
portlet, but you'll have to take it up with them.
souravm wrote:
>
> Hi All,
>
> I’ve a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>
> First time I need to access this portlet from a non-JSF (jsp) page
> which sends a http post request with some request parameters.
>
> The solution does not work when the request does not have any request
> parameter (works fine when accessed by a request with no request
> parameter).
>
> When I try to read the request parameter(s) in the constructor of the
> managed bean they come as null.
>
> I tried extending the processAction() method of MyFacesGenericPortlet.
> I read the request parameters from the ActionRequest and set them in
> RenderRequest using setRenderParameter (This anyway one has to do for
> a jsp based portlet implementation). With this approach I can read the
> request parameters in the constructor of the managed bean.
>
> I would like to validate whether this is a known limitation of
> MyFacesGenericPortlet and the solution approach mentioned above is
> right one (or any other approach is recommended) ?
>
> Any help in this regard would be highly appreciated.
>
> 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: Calling a Myfaces Portlet from a non-JSF request ..
Posted by Scott O'Bryan <da...@gmail.com>.
Sourav,
Portals don't work like you want them too. Portlets cannot receive
request parameters added to a generic portlet URL. These url's need to
be encoded. You only real option here is to have your external page
launch the portal and then the user would need to do navigation from
within the portlet itself to get to the data they need. The JSR-168
Portlet spec does not support "GET" requests - that is they do not
support modifying the parameters on a GET request after it has been
encoded (or in the case of the Action, after getting the url string).
That said, my advice would be to access your JSF application stand-alone
when launched from your external page. If that's not possible, you might
want to make your external page a portlet and look at using JSR-286
(still under development) eventing to invoke your portlet into the mode
you need. The latter suggestion is not appropriate for a short term
solution because not only is JSR-286 not final, it will also require
JSR-301 (also not final), and JSF 1.2.
Scott
souravm wrote:
>
> Hi All,
>
> I’ve a MyFaces (1.1.4) Portlet deployed in jboss portal server.
>
> First time I need to access this portlet from a non-JSF (jsp) page
> which sends a http post request with some request parameters.
>
> The solution does not work when the request does not have any request
> parameter (works fine when accessed by a request with no request
> parameter).
>
> When I try to read the request parameter(s) in the constructor of the
> managed bean they come as null.
>
> I tried extending the processAction() method of MyFacesGenericPortlet.
> I read the request parameters from the ActionRequest and set them in
> RenderRequest using setRenderParameter (This anyway one has to do for
> a jsp based portlet implementation). With this approach I can read the
> request parameters in the constructor of the managed bean.
>
> I would like to validate whether this is a known limitation of
> MyFacesGenericPortlet and the solution approach mentioned above is
> right one (or any other approach is recommended) ?
>
> Any help in this regard would be highly appreciated.
>
> 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***
>