RE: Myfaces Portlet does not work when a bean is stored in Requestscope...
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. 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. 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. 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. 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 ? However, I'll surely go through the JSR 301 spec and let me know my comments. 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
Re: MyFaces Tree2 Component
Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars). 2008/4/21, spaduri [EMAIL PROTECTED]: Hi Krishna Tomahawk, trinidad are alomost similar implementations I guess, just wondering what kind of customization you are working on the Tree... Can you explain the issue ..? thanks Suresh Thanks Nutulapati, Krishna wrote: Hi Jack, Even I need to develop a tree strtucture with checkboxes to each node. Trinad examples are appearing very gr8 for These features. But I'm unable to customise these fetures. Do you have any specific ideas on Triniad? Thanks Krishna -Original Message- From: spaduri [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2008 3:06 PM To: users@myfaces.apache.org Subject: MyFaces Tree2 Component Hi team I am planning to recommend JSF and MyFaces for the development of the application. like Navigation Tree on the left side, header, footer and body .. 1) Can any one share a piece of code to develop Dynamic Navigation Tree(like ServerSideToggling ..I will get the data from backend based on the I will build the Tree with leafs, when we click on leafs we need to call action to redirect to other jsps ) we can achieve this using MyFaces Tree2 Component,Just wondering if anybody know some information, any info is appreciated. thanks Jack -- View this message in context: http://www.nabble.com/MyFaces-Tree2-Component-tp16764781p16764781.html Sent from the MyFaces - Users mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/MyFaces-Tree2-Component-tp16764781p16802454.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: MyFaces Tree2 Component
This isn't correct; Tomahawk can be used with any JSF implementation, eg Sun's. In very old Tomahawk versions, you needed to add a shared jar if you weren't using myfaces but that was removed long ago. Regards, Simon Grzesiek schrieb: Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars).
RE: Using t:dataList with Ajax4JSF
Hi Martin,
I see your point, I will make the changes. I've been on holiday all week hence
the delay in my response, but thanks for your input on this.
Matt
-Message d'origine-
De : Martin Marinschek [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 11 avril 2008 10:28
À : MyFaces Discussion
Objet : Re: Using t:dataList with Ajax4JSF
Hi Matt,
attention - your fix will not always work as expected. What you
effectively do is you evaluate the value-binding once, and then set
the retrieved value locally. So the value-binding will only be
evaluated on the _first_ request. You should also override the getters
and setters, and do the normal JSF stuff in them.
regards,
Martin
On 4/10/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Fix if anyone's interested :
public class HtmlDataList extends
org.apache.myfaces.custom.datalist.HtmlDataList {
public Object saveState(FacesContext context) {
Object [] values = new Object[2];
values[0] = super.saveState(context);
values[1] = getItemStyleClass();
return values;
}
public void restoreState(FacesContext context, Object state) {
Object [] values = (Object[])state;
super.restoreState(context, values[0]);
setItemStyleClass((String)values[1]);
}
}
Then just override it in your config file :
component
component-typeorg.apache.myfaces.HtmlDataList/component-type
component-classcom.sag.ibee.web.gui.component.datalist.HtmlDataList/component-class
/component
Just tested and it works fine for me.
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Envoyé : jeudi 10 avril 2008 15:35
À : users@myfaces.apache.org
Objet : RE: Using t:dataList with Ajax4JSF
Ok I found the problem already, this would appear to be a bug with Tomahawk
(as I have the source attached here). Looks like itemStyleClass was
omitted from the saveState method. When I was debugging this I noticed the
value for it was null.
Listing from HtmlDataList.java
public Object saveState(FacesContext context)
{
Object values[] = new Object[17];
values[0] = super.saveState(context);
values[1] = _layout;
values[2] = _rowIndexVar;
values[3] = _rowCountVar;
values[4] = _onclick;
values[5] = _ondblclick;
values[6] = _onkeydown;
values[7] = _onkeypress;
values[8] = _onkeyup;
values[9] = _onmousedown;
values[10] = _onmousemove;
values[11] = _onmouseout;
values[12] = _onmouseover;
values[13] = _onmouseup;
values[14] = _style;
values[15] = _styleClass;
values[16] = _title;
return values;
}
As you can see itemStyleClass is not there. I'm using MyFaces 1.1.5, not
sure if this problem exists in 1.2 but we're not upgrading at this point. I
guess for now I'll just override this component to make it work. I'll see
about opening a proper bug maybe? I haven't done so before so I'm not sure
what the process is for that.
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Envoyé : jeudi 10 avril 2008 15:23
À : users@myfaces.apache.org
Objet : Using t:dataList with Ajax4JSF
Hi,
I have a small problem with t:dataList and Ajax4JSF. I'm going to step
through this in the debugger soon but maybe someone's already encountered
this.
I have a t:dataList like so:
t:dataList id=dataList var=element value=#{mbDataList.folderList}
layout=unorderedList styleClass=DataList itemStyleClass=DataList
Elsewhere I'm doing some Ajax4JSF action and I pass dataList to be
rerendered.
For the most part it rerenders correctly except it seems to omit the
'itemStyleClass=DataList' attribute. The data gets updated, but the
formatting gets broken since the lis don't have their class attribute
anymore.
Thanks,
Matt
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[OT] FacesTrace 0.9.0
Hi, FacesTrace is a small library that can be used to display several visual trace info for JSF applications, also other than the trace features, it's quite a handy tool in the learning process of JSF. The new 0.9.0 version is released, The online demo is at: http://www.nightdev.devisland.net/facestrace-example Project HomePage: http://facestrace.sourceforge.net/ Regards, Cagatay Civici
Re: facelets: howto for writing custom components
hi, but now i need to know, how exactly i do force attributes to be set You could simply output some kind of error message if a required value is not present. well, i could, of course, but i thougt there was some kind of mechanism i only need to hook into ... and, more important, how i do access components in the body of my component. Are you probably asking for ui:insert/ ? i don't know. do i? my particular problem at hand is that as result of some method of my bean i get an object. this object might be of mime type image/jpeg or text/xml. so i would like to make a component that renders the object depending on the mime type -- programatically. while the xml should be rendered in some kind of datatable the image should be rendered in some kind of simple image manipulation gui (zoom, gamma) and thus i need to render the action elements (actionButtons mostly) with predefined actions. while i am still want to know how to write my own component at all, for this particular task i am open for other suggestions as well :-) thanks
Re: Leak in saveState?
Hi, maybe comet would help here, instead of heavily pinging the server ;-) Yes, i am aware of comet but in our case it was for some reason not meaningful to use it. I can see that in some cases it may help, perhaps you wanna share the impl ? I just removed the two lines with the weak references. So, only ugly duplication of code. :) cheers, Gerald -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
how to avoid direct access to JSF pages?
Hi, Id like to prevent direct access to pages jsf, even the user is allowed to get the page requested, it's possible to allow only pages redirected or forwarded by the FacesServlet ? JSF can not redirect page under /WEB-INF/ directory, the directory wich user has no access... thanks !! -- View this message in context: http://www.nabble.com/how-to-avoid-direct-access-to-JSF-pages--tp16806675p16806675.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
is there any date spinbox component available?
Hello all, I would like to use a spinner for a date type, something similar to tr:inputNumberSpinbox, to be able to increase/ decrease dates values ( days, months, years) in an input field. Does anyone knows how to achieve this? Or will this component be available in the next release of Trinidad? Any help is appreciated! Sibel
Re: JSF Value-Binding to Model Object doesnt work
I also tried injecting FqdnBean into DeviceBean and then access model object of FqdnBean i.e. Fqdn into DeviceBean as Fqdn fqdnVO = fqdnBean.getFqdn(); Result: It returns null How is your Fqdn instance created? (normally) Oliver
Update model values is executed without a proper h:form element
Hi MyFaces implementors, we've just encountered the following behaviour in MyFaces 1.1.5: Normally the update model value phase will be executed for those input components only that are children (or descendants) of the submitted form. However, if you place such an element (for example h:inputText) outside of an h:form or accidentally inside a pure HTML form then the model values will be updated even though no active submitted form is present for these elements. I suppose that this is rather a bug than a feature. Cheers, Oliver
[Trinidad] Depth of accessibility support? Any tips?
Hi all First, my compliments to the Trinidad team - Trinidad looks like a tag library that isactually intended for use on large scale web systems. Everything seemsfully thought out and extensible. Moreover, the documentation and getting started content are comprehensive and easy to use. Very nice and all too rare among open source projects! (or commercial products...) Now for my questions. From searching the archives it looks like accessibility support via the accessibility-mode is extensive and is considered during the development and testing of new features. Which is very good news for me, as I am trying to find a tag library that plays nicely with JSF + Facelets and can be used to build 508 compliant systems! Before I plunge in, I am hoping that the Trinidad community can share their experience with accessibility (preferably 508): - Has anyone gone through a compliance audit on a Trinidad based system? How did it go? - Setting the accessibility-mode on a per user basis seems like it could provide the best of both worlds. Any issues? - Are there any components that are known to create accessibility problems? - Are there any documents on how accessibility support in Trinidad works or best practices while using it? Thanks CT Arrington Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: MyFaces Tree2 Component
Yes, that is what should be. But in my case JSF Mojarra + Tomahawk causes a lot of problems, eg : 1. First (but it doesn't matter): 2008-04-21 13:22:02 org.apache.commons.digester.Digester error SEVERE: Parse Error at line 5 column 14: Document root element faces-config, must match DOCTYPE root null. org.xml.sax.SAXParseException: Document root element faces-config, must match DOCTYPE root null. when faces-config.xml is successfully validated and in 100% is good. 2. My real problem is this exception: 2008-04-21 13:29:52 org.apache.myfaces.webapp.filter.ExtensionsFilter doFilter SEVERE: Exception wile retrieving addResource javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.myfaces.shared_tomahawk.config.MyfacesConfig (but the same project + MyFaces + Tomahawk works perfect). This exception takes place when I try to add `Tomahawk-1.6.jar` to my projet with jsf-api.jar and jsf-impl.jar from SUN JSF. I need Tomahawk for e.g files upload. Regards 2008/4/21, [EMAIL PROTECTED] [EMAIL PROTECTED]: This isn't correct; Tomahawk can be used with any JSF implementation, eg Sun's. In very old Tomahawk versions, you needed to add a shared jar if you weren't using myfaces but that was removed long ago. Regards, Simon Grzesiek schrieb: Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars).
Re: MyFaces Tree2 Component
We should really use a different thread for this issue. However... Item (1) just looks like a plain old bug in tomahawk. Could you please post the first few lines of your faces-config.xml file? I don't know why (2) is happening for you... [EMAIL PROTECTED]:~/.m2/repository/org/apache/myfaces/tomahawk/tomahawk/1.1.6 jar tf tomahawk-1.1.6.jar| grep MyfacesConfig org/apache/myfaces/shared_tomahawk/config/MyfacesConfig.class So the MyfacesConfig class is present in the tomahawk 1.1.6 jarfile. The problem must therefore be that some class it depends on cannot be found (NoClassDefFound errors are a pain to track down, due to insufficient info from Sun's JVM). Is there anything more useful in the stacktrace? Just FYI, Tomahawk 1.1.7-SNAPSHOT definitely can be run on Sun's RI. If you (1) check out the tomahawk examples: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/examples (2) add the apache snapshot repo to your ~/.m2/settings.xml file (3) type cd examples/simple mvn -Djsf=ri12 jetty:run then the examples will start up using the sun RI, and can be accessed via http://localhost:8080 I'm not aware of any reason why 1.1.6 would not also run (though the latest examples code needs 1.1.7) Regards, Simon Grzesiek schrieb: Yes, that is what should be. But in my case JSF Mojarra + Tomahawk causes a lot of problems, eg : 1. First (but it doesn't matter): 2008-04-21 13:22:02 org.apache.commons.digester.Digester error SEVERE: Parse Error at line 5 column 14: Document root element faces-config, must match DOCTYPE root null. org.xml.sax.SAXParseException: Document root element faces-config, must match DOCTYPE root null. when faces-config.xml is successfully validated and in 100% is good. 2. My real problem is this exception: 2008-04-21 13:29:52 org.apache.myfaces.webapp.filter.ExtensionsFilter doFilter SEVERE: Exception wile retrieving addResource javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.myfaces.shared_tomahawk.config.MyfacesConfig (but the same project + MyFaces + Tomahawk works perfect). This exception takes place when I try to add `Tomahawk-1.6.jar` to my projet with jsf-api.jar and jsf-impl.jar from SUN JSF. I need Tomahawk for e.g files upload. Regards 2008/4/21, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: This isn't correct; Tomahawk can be used with any JSF implementation, eg Sun's. In very old Tomahawk versions, you needed to add a shared jar if you weren't using myfaces but that was removed long ago. Regards, Simon Grzesiek schrieb: Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars).
Re: Leak in saveState?
Gerald Müllan-3 wrote: I can see that in some cases it may help, perhaps you wanna share the impl ? I just removed the two lines with the weak references. So, only ugly duplication of code. :) Gerald, at the risk of sounding like a novice, can you point me to the lines of code with the weak references that you mention above? This would be a HUGE help. Thanks, - Will -- View this message in context: http://www.nabble.com/Leak-in-saveState--tp16356703p16807937.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Leak in saveState?
wbirkhead schrieb:
Gerald Müllan-3 wrote:
I can see that in some cases it may help, perhaps you wanna share the
impl ?
I just removed the two lines with the weak references. So, only ugly
duplication of code. :)
Gerald, at the risk of sounding like a novice, can you point me to the lines
of code with the weak references that you mention above? This would be a
HUGE help.
JspStateManagerImpl has this method:
public synchronized void add(FacesContext context, Object state)
{
Object key = new SerializedViewKey(context);
_serializedViews.put(key, state);
while (_keys.remove(key));
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() views)
{
key = _keys.remove(0);
Object oldView = _serializedViews.remove(key);
if (oldView != null)
{
getOldSerializedViewsMap().put(key, oldView);
}
}
}
The second while loop is trimming the strong-referenced pool down to
the necessary size, and adding the removed entries into the weak pool.
So just commenting out the call to
getOldSerializedViewsMap().put(key, oldView);
should do the trick.
Regards,
Simon
Two schedule components on one page
Hi everybody Is there a way to put two tomahawk's schedule components on one page? If i do this only one is rendered. Thx
Re: MyFaces Tree2 Component
Hi there I am planning to recommend JSF and MyFaces for the development of the application. like Navigation Tree on the left side, header, footer and body .. 1) Can any one share a piece of code or share any Ideas to develop Dynamic Navigation Tree(like ServerSideToggling ..I will get the data from backend based on the I will build the Tree with leafs, when we click on leafs we need to call action to redirect to other jsps ) we can achieve this using MyFaces Tree2 Component,Just wondering if anybody know some information, any info is appreciated. Thanks Jack [EMAIL PROTECTED] wrote: This isn't correct; Tomahawk can be used with any JSF implementation, eg Sun's. In very old Tomahawk versions, you needed to add a shared jar if you weren't using myfaces but that was removed long ago. Regards, Simon Grzesiek schrieb: Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars). -- View this message in context: http://www.nabble.com/MyFaces-Tree2-Component-tp16764781p16808008.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Two schedule components on one page
Sorry it was my mistake. I just put same binding in this two components. 2008/4/21, Tomasz Kaczor [EMAIL PROTECTED]: Hi everybody Is there a way to put two tomahawk's schedule components on one page? If i do this only one is rendered. Thx
Re: Myfaces Portlet does not work when a bean is stored in Requestscope...
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
RE: how to avoid direct access to JSF pages?
I *think* if you use spring-web-flow 2.x, you can achieve this... -Original Message- From: lmk [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 11:14 AM To: users@myfaces.apache.org Subject: how to avoid direct access to JSF pages? Hi, Id like to prevent direct access to pages jsf, even the user is allowed to get the page requested, it's possible to allow only pages redirected or forwarded by the FacesServlet ? JSF can not redirect page under /WEB-INF/ directory, the directory wich user has no access... thanks !! -- View this message in context: http://www.nabble.com/how-to-avoid-direct-access-to-JSF-pages--tp1680667 5p16806675.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Update model values is executed without a proper h:form element
The form just produces an HTML form. All UIComponents in the tree are decoded, validated and updated per the specification. I believe that the core input* and select* controls do not update if the submittedValue for an EditableValueHolder is null. Therefore, you should check to see what form values are being sent to the server and if need be, check the decoding of the components to see if they are getting a null or non-null value. -Andrew On Mon, Apr 21, 2008 at 5:21 AM, Oliver Becker [EMAIL PROTECTED] wrote: Hi MyFaces implementors, we've just encountered the following behaviour in MyFaces 1.1.5: Normally the update model value phase will be executed for those input components only that are children (or descendants) of the submitted form. However, if you place such an element (for example h:inputText) outside of an h:form or accidentally inside a pure HTML form then the model values will be updated even though no active submitted form is present for these elements. I suppose that this is rather a bug than a feature. Cheers, Oliver
Re: JSF Value-Binding to Model Object doesnt work
Hi Andrew
Thanks for quick response.
I tried using managed property but it still returns null.
I do have ui:composition in my code but what i was wondering is when i use
ui:include to include another xhtml file, if i dont have html and body
tags in this xhtml file then how can i use jsf tags to build my page.
Here is the snippet of my included xhtml file
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:a4j=https://ajax4jsf.dev.java.net/ajax;
xmlns:s=http://myfaces.apache.org/sandbox;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:c=http://java.sun.com/jstl/core;
t:saveState value=#{fqdnBean.fqdn}/
h:outputLabelh:outputText value=Host Name
/h:outputText
style=color: #DD0707 value= * //h:outputLabel
h:inputText id=hostName
value=#{fqdnBean.fqdn.name} style=width:
230px
styleClass=required max-63
/h:inputText
/h:panelGrid
Andrew Robinson-5 wrote:
See my reply on the facelets list. You should not be referencing the
request context to get a managed bean instance. Either use a managed
property, or build an EL expression (or binding for 1.1) and obtain it
that way.
Beans are lazy loaded and thus should be obtained through the proper API.
If you are using facelets, why is there a f:view in your code and why
are you not using ui:composition to make sure you do not have 2 BODY
tags?
On Sun, Apr 20, 2008 at 6:59 PM, bansi [EMAIL PROTECTED] wrote:
I also tried injecting FqdnBean into DeviceBean and then access model
object
of FqdnBean i.e. Fqdn into DeviceBean as
Fqdn fqdnVO = fqdnBean.getFqdn();
Result:
It returns null
bansi wrote:
Here is the code sample
html
body
f:view
h:form id=updateDeviceForm
h:panelGrid
..
..
h:inputText id=deviceName value=#{deviceBean.name} style=width:
230px
styleClass=required max-63
/h:panelGrid
h:panelGrid
ui:include src=fqdnForm.xhtml/ui:include
/h:panelGrid
/f:view
/body
/html
Here is the snippet of fqdnForm.xhmtl which has value binding of name
form
field to model object Fqdn
body
h:panelGrid columns=3 styleClass=detail columnClasses=label
h:inputText id=hostName value=#{fqdnBean.fqdn. name}
style=width:
230px
styleClass=required max-63
/h:inputText
h:inputHidden id=fqdnHidden value=#{fqdnBean.fqdn}
converter=#{fqdnConverter}/h:inputHidden
/h:panelGrid
/body
The problem is i am unable to access model object fqdn in deviceBean
and
ofcourse quite obviously i am able to successfully access Fqdn model
object in FqdnBean.
But as fqdnForm is included in deviceForm i am accessing Fqdn model
object
or FqdnBean in deviceBean as follows and it returns NULL
1)
FqdnBean fqdnBean = (FqdnBean)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(fqdnBean);
2)UIInput fqdnComp = (UIInput) FacesUtils.findComponentById(null,
fqdnHidden);
Any pointers/suggestions will be highly appreciated
--
View this message in context:
http://www.nabble.com/JSF-Value-Binding-to-Model-Object-doesnt-work-tp16785936p16800996.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/JSF-Value-Binding-to-Model-Object-doesnt-work-tp16785936p16808289.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF Value-Binding to Model Object doesnt work
what do your registrations look like for your two beans in your
faces-config.xml? Have you tried using EL to obtain the reference to
fqdnBean?
As far as ui:composition I usually have 1 template for my pages with
the HTML and BODY and then use ui:composition for everything else:
template.xhtml:
htmlbody.../body/html
page1.xhtml:
htmlbodyui:composition
template=/template.xhtml.../ui:composition/body/html
included1.xhtml:
htmlbodyui:composition.../ui:composition/body/html
-Andrew
On Mon, Apr 21, 2008 at 11:33 AM, bansi [EMAIL PROTECTED] wrote:
Hi Andrew
Thanks for quick response.
I tried using managed property but it still returns null.
I do have ui:composition in my code but what i was wondering is when i use
ui:include to include another xhtml file, if i dont have html and body
tags in this xhtml file then how can i use jsf tags to build my page.
Here is the snippet of my included xhtml file
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:a4j=https://ajax4jsf.dev.java.net/ajax;
xmlns:s=http://myfaces.apache.org/sandbox;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:c=http://java.sun.com/jstl/core;
t:saveState value=#{fqdnBean.fqdn}/
h:outputLabelh:outputText value=Host
Name /h:outputText
style=color: #DD0707 value= * //h:outputLabel
h:inputText id=hostName
value=#{fqdnBean.fqdn.name} style=width:
230px
styleClass=required max-63
/h:inputText
/h:panelGrid
Andrew Robinson-5 wrote:
See my reply on the facelets list. You should not be referencing the
request context to get a managed bean instance. Either use a managed
property, or build an EL expression (or binding for 1.1) and obtain it
that way.
Beans are lazy loaded and thus should be obtained through the proper API.
If you are using facelets, why is there a f:view in your code and why
are you not using ui:composition to make sure you do not have 2 BODY
tags?
On Sun, Apr 20, 2008 at 6:59 PM, bansi [EMAIL PROTECTED] wrote:
I also tried injecting FqdnBean into DeviceBean and then access model
object
of FqdnBean i.e. Fqdn into DeviceBean as
Fqdn fqdnVO = fqdnBean.getFqdn();
Result:
It returns null
bansi wrote:
Here is the code sample
html
body
f:view
h:form id=updateDeviceForm
h:panelGrid
..
..
h:inputText id=deviceName value=#{deviceBean.name} style=width:
230px
styleClass=required max-63
/h:panelGrid
h:panelGrid
ui:include src=fqdnForm.xhtml/ui:include
/h:panelGrid
/f:view
/body
/html
Here is the snippet of fqdnForm.xhmtl which has value binding of name
form
field to model object Fqdn
body
h:panelGrid columns=3 styleClass=detail columnClasses=label
h:inputText id=hostName value=#{fqdnBean.fqdn. name}
style=width:
230px
styleClass=required max-63
/h:inputText
h:inputHidden id=fqdnHidden value=#{fqdnBean.fqdn}
converter=#{fqdnConverter}/h:inputHidden
/h:panelGrid
/body
The problem is i am unable to access model object fqdn in deviceBean
and
ofcourse quite obviously i am able to successfully access Fqdn model
object in FqdnBean.
But as fqdnForm is included in deviceForm i am accessing Fqdn model
object
or FqdnBean in deviceBean as follows and it returns NULL
1)
FqdnBean fqdnBean = (FqdnBean)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(fqdnBean);
2)UIInput fqdnComp = (UIInput) FacesUtils.findComponentById(null,
fqdnHidden);
Any pointers/suggestions will be highly appreciated
--
View this message in context:
http://www.nabble.com/JSF-Value-Binding-to-Model-Object-doesnt-work-tp16785936p16800996.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
View this message in context:
http://www.nabble.com/JSF-Value-Binding-to-Model-Object-doesnt-work-tp16785936p16808289.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: MyFaces Tree2 Component
first of all, thanks for you help... ?xml version='1.0' encoding='UTF-8'? !-- === FULL CONFIGURATION FILE == -- faces-config version=1.2 xmlns=http://java.sun.com/xml/ns/javaee; . It still gives an error : SEVERE: Parse Error at line 2 column 14: Document root element faces-config, must match DOCTYPE root null. org.xml.sax.SAXParseException: Document root element faces-config, must match DOCTYPE root null. (2) So the MyfacesConfig class is present in the tomahawk 1.1.6 jarfile. Yes, I also checked this and 'org.apache.myfaces.shared_tomahawk.config.MyfacesConfig' class is where it should be. So this is strange following exception: javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.myfaces.shared_tomahawk.config.MyfacesConfig is caused by this line In my web.xml : filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class I consider that it would be a bug somewhere, but never mind. At least i'll have to change my JSF implementation, because with myfaces it works. Anyway if you don't know how to solve this exception, i don't want waste your time regards 2008/4/21, [EMAIL PROTECTED] [EMAIL PROTECTED]: We should really use a different thread for this issue. However... Item (1) just looks like a plain old bug in tomahawk. Could you please post the first few lines of your faces-config.xml file? I don't know why (2) is happening for you... [EMAIL PROTECTED]:~/.m2/repository/org/apache/myfaces/tomahawk/tomahawk/1.1.6 jar tf tomahawk-1.1.6.jar| grep MyfacesConfig org/apache/myfaces/shared_tomahawk/config/MyfacesConfig.class So the MyfacesConfig class is present in the tomahawk 1.1.6 jarfile. The problem must therefore be that some class it depends on cannot be found (NoClassDefFound errors are a pain to track down, due to insufficient info from Sun's JVM). Is there anything more useful in the stacktrace? Just FYI, Tomahawk 1.1.7-SNAPSHOT definitely can be run on Sun's RI. If you (1) check out the tomahawk examples: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/examples (2) add the apache snapshot repo to your ~/.m2/settings.xml file (3) type cd examples/simple mvn -Djsf=ri12 jetty:run then the examples will start up using the sun RI, and can be accessed via http://localhost:8080 I'm not aware of any reason why 1.1.6 would not also run (though the latest examples code needs 1.1.7) Regards, Simon Grzesiek schrieb: Yes, that is what should be. But in my case JSF Mojarra + Tomahawk causes a lot of problems, eg : 1. First (but it doesn't matter): 2008-04-21 13:22:02 org.apache.commons.digester.Digester error SEVERE: Parse Error at line 5 column 14: Document root element faces-config, must match DOCTYPE root null. org.xml.sax.SAXParseException: Document root element faces-config, must match DOCTYPE root null. when faces-config.xml is successfully validated and in 100% is good. 2. My real problem is this exception: 2008-04-21 13:29:52 org.apache.myfaces.webapp.filter.ExtensionsFilter doFilter SEVERE: Exception wile retrieving addResource javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not initialize class org.apache.myfaces.shared_tomahawk.config.MyfacesConfig (but the same project + MyFaces + Tomahawk works perfect). This exception takes place when I try to add `Tomahawk-1.6.jar` to my projet with jsf-api.jar and jsf-impl.jar from SUN JSF. I need Tomahawk for e.g files upload. Regards 2008/4/21, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: This isn't correct; Tomahawk can be used with any JSF implementation, eg Sun's. In very old Tomahawk versions, you needed to add a shared jar if you weren't using myfaces but that was removed long ago. Regards, Simon Grzesiek schrieb: Personally I regret tomahawk can't be used without myfaces (dependencies on `_shared` jars).
[Trinidad] Trinidad Dialog Framework and Spring WebFlow
Has anyone used the Trinidad Dialog Framework with Spring WebFlow? If so, can you share any tips that you may have on getting the two frameworks to work together. I am a little confused on how to map the Trinidad dialogs (view Id is dialog:someDialog) to the equivalent Spring flow. Since the navigation with a Trinidad dialog is returned to the originating page through the call to returnFromDialog(), there is not a view id to use in the Spring Flow transition on= attribute. Should trinidad dialogs be mapped to Spring Flows at all or can only non-dialog navigation be used in Spring Flows? Thanks for any help in advance. -Richard
Re: View state- security
Kamal Parmar wrote: Hello People, I am pen-tester so please bear with any lack of knowledge on my part ;) I am reviewing a MyFaces web application which appears to have very large values for View State being posted back. The View State, once base64 decoded and gunzipped, measures anywhere between 2000 to an amazing 7 characters. Some of the characters are binary and cannot be viewed in a text editor. I am guessing this is because it is serialized data so it does not show as character data. As an indication it starts with: ...java.lang.Object...XY..s..xp..srsr Gorg.apache.myfaces.application.TreeStructureManager$TreeStructComponentFYØœJöÏ [childrentJ[Lorg/apache/myfaces/application/TreeStructureManager$TreeStructComponent;L _componentClasst Ljava/lang/String;L _componentIdq ~ [ _facetst [Ljava/lang/Object;xpur J[Lorg.apache.myfaces.application.TreeStructureManager$TreeStructComponent;º¬'È…ª xp sq ~ uq ~ sq ~ pt )javax.faces.component.html.HtmlOutputTextt Then I get names of beans, properties, methods, navigation actions (next actions) and many repititions of WEB-INF and html documents within it. My questions are: 1. How can I deserialise the string without having access to the application source code itself? The non-alphanumeric characters really throw me off-track and I cannot determine their relevance You would need to add your own StateManager which would serialize/deserialize the data yourself. Seems to me though that this makes it MORE secure rather then less. 2. Is it possible for an attacker to bypass application controls by inserting references to beans, properties, methods, navigation actions, etc which the attacker by design should not really have access to? I am thinking it might be possible for an attacker to inject ViewState which deserializes to a component tree the attacker should never have access to. These are component values, not model information. While I wouldn't say it's impossible, I don't think there is much exposure here. It's passed security experts at Oracle, IBM, and Sun. If you are worried about it, turn on server-side state saving. This will simply save a token and the view-state would then be stored solely on the server. Scott Hope this makes sense. Any help much appreciated. cheers Kelly
panelTabbedPane submit on serverside tab-switching
Hello everyone, I have a form containing a tomahawk panelTabbedPane which contains 4 tabbed panels. All tabbed panels contain a lot of input-fields. The problem is, as someone mentioned before 2 years ago, that the data entered in the form on TAB_A will be lost, when I switch to TAB_B, provided that server-side-tab-switching is activated. What I would like to have is a feature which writes the data entered into JSF-bound-bean-properties before the actual tabswitching is done (in other words, I need a submit before tab-switching). Please note that I would really like to use server-side tabb-switching, as the tabs contain lots of data and the bandwidth is very limited. Please also note, that I do not like to add a onvalueChange-JScript to all input fields. (Somehow autoscroll does not work (to be investigated).) Any ideas: What about a phase listener, which does this work manually? Regards and thanks in advance. Christian Kölle
AW: panelTabbedPane submit on serverside tab-switching
Sorry, I forgot to mention this: I also would really like to use server-side tab switching, because the various tabs show different views on the same data, i.e. if I enter a address on TAB_C and then switch to TAB_A the value entered should be shown in a different way. So the TABS represent different views on the same model. Regards Christian Christian Kölle wrote: | Hello everyone, | | I have a form containing a tomahawk panelTabbedPane which contains 4 | tabbed panels. All tabbed panels contain a lot of input-fields. | | The problem is, as someone mentioned before 2 years ago, that the | data entered in the form on TAB_A will be lost, when I switch to | TAB_B, provided that server-side-tab-switching is activated. What I | would like to have is a feature which writes the data entered into | JSF-bound-bean-properties before the actual tabswitching is done (in | other words, I need a submit before tab-switching). | | Please note that I would really like to use server-side | tabb-switching, as the tabs contain lots of data and the bandwidth is | very limited. | | Please also note, that I do not like to add a onvalueChange-JScript | to all input fields. (Somehow autoscroll does not work (to be | investigated).) | | Any ideas: What about a phase listener, which does this work manually? | | Regards and thanks in advance. | Christian Kölle
difficulty implementing t:columns
Hello,
I am having difficulty implementing t:columns and keep getting this error
message (using either MyFaces 1.2.2 or JSF 1.2_07).
java.lang.IllegalStateException: UIColumns component must be a child
of a UIData component
I've attached my JSP and my backing bean. What am I missing here?
testColumns.jsp
%@ taglib prefix=h uri=http://java.sun.com/jsf/html; %
%@ taglib prefix=f uri=http://java.sun.com/jsf/core; %
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
f:view
html
headtitleSimple jsp page/title/head
body
t:dataTable
value=#{TestColumnsBean.rows}
var=row
preserveDataModel=true
t:columns
value=#{row.data}
var=column
h:outputText value=#{column}/
/t:columns
/t:dataTable
/body
/html
/f:view
this is my backing bean:
import java.util.ArrayList;
import java.util.List;
public class TestColumnsBean {
private ListTestRow rows;
public TestColumnsBean() {
rows=new ArrayListTestRow();
for (int i=0; i4; i++)
{
rows.add(new TestRow(i^2));
}
}
public ListTestRow getRows() {
return rows;
}
public void setRows(ListTestRow rows) {
this.rows = rows;
}
public class TestRow {
private static Logger logger =
Logger.getLogger(TestRow.class.getName());
private ListLong data;
public TestRow(long start) {
data=new ArrayListLong();
for (int i=0; i5; i++)
data.add(start+i);
}
public ListLong getData() {
return data;
}
public void setData(ListLong data) {
this.data = data;
}
}
}
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
RE: Myfaces Portlet does not work when a bean is stored in Requestscope...
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
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
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
Re: Myfaces Portlet does not work when a bean is stored in Requestscope...
Hey Souravm, are you on the dev list? We should probably continue this there. Scott souravm wrote: 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
RE: Myfaces Portlet does not work when a bean is stored in Requestscope...
Ok. I'm not currently in dev list. Let me add myself there and let you know. Regards, Sourav -Original Message- From: Scott O'Bryan [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 5:05 PM To: MyFaces Discussion Subject: Re: Myfaces Portlet does not work when a bean is stored in Requestscope... Hey Souravm, are you on the dev list? We should probably continue this there. Scott souravm wrote: 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
