Hi Scott, Here u go.
Regards, Sourav ________________________________________ From: Scott O'Bryan [EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 8:44 AM To: MyFaces Development Subject: Re: Upgrading to MyFace 1.2 in Jboss Portal Server giving problem... Oh sorry, I'm also going to need your portlet.xml. You're correct, I didn't need you faces config. Scott souravm wrote: > Here u go. > > Please note that > > 1. These are the web.xml and faces-config.xml from one of the inbuilt portal > applications (admin application) in JBoss Portal Server > 2. There is no change in faces-config.xml i did for moving from myfaces 1.1.5 > to 1.2.2 > 3. In web.xml I changed the Faces Servlet name and also added the listener > name. Even without the listener name it does not work. The listener name is > anyway also present there in web.xml file in Tomcat's conf folder. > > Regards, > Sourav > > > ________________________________________ > From: Scott O'Bryan [EMAIL PROTECTED] > Sent: Tuesday, April 22, 2008 6:03 AM > To: MyFaces Development > Cc: [email protected] > Subject: Re: Upgrading to MyFace 1.2 in Jboss Portal Server giving problem > ... > > Can you post your web.xml & faces-config so I can take a quick look at > them? > > On Apr 22, 2008, at 12:00 AM, souravm <[EMAIL PROTECTED]> wrote: > > >> It is listed. >> >> Actually the same code and configuration was working fine with >> myfaces 1.1.5. >> I just changed the MyFacesGenericPortlet to FacesGenericPortlet in >> all relevant places. >> >> ----- Original Message ----- >> From: Scott O'Bryan <[EMAIL PROTECTED]> >> To: MyFaces Development <[email protected]> >> Cc: MyFaces Development <[email protected]> >> Sent: Mon Apr 21 22:18:42 2008 >> Subject: Re: Upgrading to MyFace 1.2 in Jboss Portal Server giving >> problem ... >> >> The bridge should work with facelets although I don't know how much >> testing has been done on it. I'm assuming that you don't have the >> faces servlet listed in your web.xml? >> >> On Apr 21, 2008, at 8:51 PM, souravm <[EMAIL PROTECTED]> wrote: >> >> >>> Solved the issue mentioned below. It was due to mix of myfaces jar >>> in the class path. >>> >>> Now stuck with the following issue - >>> >>> The FacesServlet fails to initialize. It says No Mapping Of >>> FacesServlet found. Abort Initializing MyFaces. >>> >>> I'm using Facelets instead of jsp. >>> >>> Is that the root cause of the problem ? >>> >>> Regards, >>> Sourav >>> >>> -----Original Message----- >>> From: souravm [mailto:[EMAIL PROTECTED] >>> Sent: Monday, April 21, 2008 5:19 PM >>> To: [email protected] >>> Subject: FW: Myfaces Portlet does not work when a bean is stored >>> inRequestscope... >>> >>> Just forwarding the message from user group. >>> >>> -----Original Message----- >>> From: souravm [mailto:[EMAIL PROTECTED] >>> 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:[EMAIL PROTECTED] >>> 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:[EMAIL PROTECTED] >>>> 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:[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*** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>
<?xml version="1.0" encoding="UTF-8"?> <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ JBoss, a division of Red Hat ~ ~ Copyright 2006, Red Hat Middleware, LLC, and individual ~ ~ contributors as indicated by the @authors tag. See the ~ ~ copyright.txt in the distribution for a full listing of ~ ~ individual contributors. ~ ~ ~ ~ This is free software; you can redistribute it and/or modify it ~ ~ under the terms of the GNU Lesser General Public License as ~ ~ published by the Free Software Foundation; either version 2.1 of ~ ~ the License, or (at your option) any later version. ~ ~ ~ ~ This software is distributed in the hope that it will be useful, ~ ~ but WITHOUT ANY WARRANTY; without even the implied warranty of ~ ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ~ ~ Lesser General Public License for more details. ~ ~ ~ ~ You should have received a copy of the GNU Lesser General Public ~ ~ License along with this software; if not, write to the Free ~ ~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA ~ ~ 02110-1301 USA, or see the FSF site: http://www.fsf.org. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--> <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"; version="1.0"> <portlet> <description>Administration Portlet</description> <portlet-name>AdminPortlet</portlet-name> <display-name>Administration Portlet</display-name> <portlet-class>javax.portlet.faces.GenericFacesPortlet</portlet-class> <init-param> <name>default-view</name> <value>/WEB-INF/jsf/objects.xhtml</value> </init-param> <supports> <mime-type>text/html</mime-type> <portlet-mode>VIEW</portlet-mode> </supports> <portlet-info> <title>Management Portlet</title> <keywords>management,admin</keywords> </portlet-info> </portlet> <portlet> <description>Dashboard Configurator Portlet</description> <portlet-name>DashboardConfigPortlet</portlet-name> <display-name>Dashboard Configurator Portlet</display-name> <portlet-class>javax.portlet.faces.GenericFacesPortlet</portlet-class> <init-param> <name>default-view</name> <value>/WEB-INF/jsf/dashboard/dashboard.xhtml</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> <portlet-mode>VIEW</portlet-mode> </supports> <portlet-info> <title>Dashboard Configurator Portlet</title> <keywords>management,admin</keywords> </portlet-info> </portlet> </portlet-app>
