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*** >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> >
