Simple container tag in Trinidad for PPR (Partial Page Rendering)
Is there some container tag (generating span or maybe div, something like h:panelGroup /), which content be updated by using partialTriggers attribute ? I can't find that :/ -- View this message in context: http://old.nabble.com/Simple-container-tag-in-Trinidad-for-PPR-%28Partial-Page-Rendering%29-tp29579928p29579928.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Simple container tag in Trinidad for PPR (Partial Page Rendering)
tr:panelGroupLayout/ is often used for this purpose, but it renders a table, so it's quite verbose... Regards, Cedric Durmont 2010/8/31 marioosh.net marioosh@gmail.com: Is there some container tag (generating span or maybe div, something like h:panelGroup /), which content be updated by using partialTriggers attribute ? I can't find that :/ -- View this message in context: http://old.nabble.com/Simple-container-tag-in-Trinidad-for-PPR-%28Partial-Page-Rendering%29-tp29579928p29579928.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: double click problem in JSF
Don't try to catch a double-click event. Instead, try to : - catch an onclick event - use it to disable the link - return true, so that this first click will actually do something. The following clicks should not happen because you just disabled/hidden the link Regards Cedric 2010/8/31 yogeen honnavar yog...@yahoo.com: Scott, Yes am also trying javascript solution. but the problem is for h:commandlink onclick event is generated by myfaces. and am not successful at trying to catch double click event also since the form is being submitted even though i catch double click event and say return. can u pls give some code snippet to handle this using javascript. also i read about shale s:token and some other solutions being used to solve this problem. any idea ? regards -yogeen --- On Mon, 30/8/10, Scott O'Bryan darkar...@gmail.com wrote: From: Scott O'Bryan darkar...@gmail.com Subject: Re: double click problem in JSF To: MyFaces Discussion users@myfaces.apache.org Date: Monday, 30 August, 2010, 6:22 PM Yogeen, This is standard link behavior. Short of writing JavaScript to intercept the event and handle double click, here is not much I think you can do. Sent from my iPhone On Aug 29, 2010, at 9:45 PM, yogeen honnavar yog...@yahoo.com wrote: Dear users, We are using myfaces-1.1.5 with tomcat. We have a problem, when a user double clicks on a h:commandlink 2 submissions are sent to the server and hence the application reports an error. Can anybody suggest a solution to the double click problem. regards -yogeen
Re: Simple container tag in Trinidad for PPR (Partial Page Rendering)
Thanks for Your answer.
I have some problem with tr:panelGroupLayout:
When i click addProduct button i get more and more tables :/
h:form
div
tr:commandLink id=addProduct text=add random product
partialSubmit=true action=#{testBean.addRandomProduct} /
tr:panelGroupLayout partialTriggers=addProduct
table border=1
c:forEach items=#{testBean.allProducts}
var=product
tr
td#{product.id}/td
td#{product.name}/td
td#{product.owner.id}/td
tdtr:commandLink
id=deleteProduct text=delete
partialSubmit=true
actionListener=#{testBean.deleteProduct}
action=#{testBean.deleteProduct}
f:param name=id
value=#{product.id} /
/tr:commandLink/td
/tr
/c:forEach
/table
/tr:panelGroupLayout
/div
/h:form
Cédric Durmont wrote:
tr:panelGroupLayout/ is often used for this purpose, but it renders
a table, so it's quite verbose...
Regards,
Cedric Durmont
2010/8/31 marioosh.net marioosh@gmail.com:
Is there some container tag (generating span or maybe div, something like
h:panelGroup /), which content be updated by using partialTriggers
attribute ? I can't find that :/
--
View this message in context:
http://old.nabble.com/Simple-container-tag-in-Trinidad-for-PPR-%28Partial-Page-Rendering%29-tp29579928p29579928.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/Simple-container-tag-in-Trinidad-for-PPR-%28Partial-Page-Rendering%29-tp29579928p29580229.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Problem while uplaoding files using t:inputFileUpload
Hi, I am using t:inputFileUpload for uploading files. Using the following jars: - myfaces-api-1.1.5.jar - myfaces-impl-1.1.5.jar - tomahawk-1.1.8.jar - commons-io-1.3.2.jar - commons-fileupload-1.2.1.jar Sometimes, it fails to upload file. The following exceptions occur: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Connection reset Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) or org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly Can someone help me, regarding this issue? Thanks in advance. -- View this message in context: http://old.nabble.com/Problem-while-uplaoding-files-using-%3Ct%3AinputFileUpload%3E-tp29580273p29580273.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Problem while uplaoding files using t:inputFileUpload
is there any proxy/webserver between java server and client? maybe there is some constraints installed... 2010/8/31 verginie verginie.theb...@wipro.com Hi, I am using t:inputFileUpload for uploading files. Using the following jars: - myfaces-api-1.1.5.jar - myfaces-impl-1.1.5.jar - tomahawk-1.1.8.jar - commons-io-1.3.2.jar - commons-fileupload-1.2.1.jar Sometimes, it fails to upload file. The following exceptions occur: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Connection reset Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) or org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly Can someone help me, regarding this issue? Thanks in advance. -- View this message in context: http://old.nabble.com/Problem-while-uplaoding-files-using-%3Ct%3AinputFileUpload%3E-tp29580273p29580273.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: PortletBridge starting portlet problem
Hey Scott, Yves, perhaps this is similar to TRINIDAD-195 ? Is this happening on unix,linux or apple OS ? -Matthias On Mon, Aug 30, 2010 at 5:39 PM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: It means Factory already available for this class loader Thanks... Scott O'Bryan a écrit : Yay.. Exception translation at work. Yves, can you tell us what that message states in English? Sorry, half the characters didn't come through. Sent from my iPhone On Aug 30, 2010, at 6:50 AM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: Hi Michael, I just come back from holidays. I try my app with this environment: trinidad 1.2.15-SNAPSHOT (30/08/2010) portlet-bridge 1.0.0 (distribution) myfaces 1.2.9 (distribution) portlet-api-1.0 pluto... 1.1.7 uPortal-3.2.1 The result is : Caused by: java.lang.IllegalStateException: Factory d�j� disponible pour ce chargeur de classe. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.lt;initgt;(FacesContextFactoryImpl.java:86) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.getFacesContext(BridgeImpl.java:943) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:513) And when the portlet is refreshed, all is ok ! I see this recent message in the list: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader, I think that the portal make a double request to the portlet ? May be can you test my app in your environment with this zip file : https://bigfile.univ-lille1.fr/get?k=QxI6pCDOMWM12k0bTdJ Thank you in advance. Michael Freedman a �crit : This feels more environmental than anything else. Is this still just the situation when accessing from an iPhone user-agent? The regular user-agent still works fine? Can you send me a complete description of your environment? I.e. Specific Trinidad version, Faces make (Mojarra or Myfaces?) and version, appserver version which includes portlet container make (pluto ???) and version? What has me stumped here is that the line you indicate is throwing the null pointer exception: switch ((Bridge.PortletPhase) mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE)) The instance is constructed with the requestObject which is passed by the bridge's externalContext which gets it in its constructor -- so unless a release() occurred I don't see how its null. Likewise the bridge's doFacesRender (further down the stack) has already set the request attribute we are looking for here -- which means it should be around unless a spurious release occurred. We have encountered problems releasing attributes in some servers which the portal server/container is treating specially because of their prefix like javax.* -- but I haven't seen any issues in setting/retrieving. So first thing we need to do is figure out what is causing the NPE. Is the request in fact null here? Or the attribute not there? (My bet is on the later). And if the later, why it isn't there as its clearly been set. Are you able to do some debugging to answer some of these questions? If not let me know as i can build you one-of bridge jars that will write extra info to the logs to get us the info -- it will just take a much longer time as we get each new piece of information we will have to dig deeper/send a new jar (and I only work Tues-Thurs). Another idea is to try a different environment. Maybe try running this is in the Tomcat/Pluto environment and see if the behavior is the same or not. That will at least rule out the app server (and portlet container -- though if I recall its Pluto anyway). FYI ... The bridge does work with Trinidad as its used heavily here at Oracle and I also do random testing on my own however everyone's situation is different so it likely not bug free ... just want you to know you aren't the first. -Mike- On 7/12/2010 1:51 AM, Yves Deschamps wrote: Thank you Michael, I change little things and now, i have this NPE: Caused by: java.lang.NullPointerException at org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaders.initHeaderMap(PortletRequestHeaders.java:109) at org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaders.getHeader(PortletRequestHeaders.java:48) at
Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader
Jakub, this does NOT happen on windows, right ? -Matthias On Tue, Aug 24, 2010 at 4:11 PM, Jakub Kahovec jakub.kaho...@googlemail.com wrote: Hi Matthias, thanks for your reply. Well, brief steps how to reproduce this are already in the ticket (not much descriptive though :-). The scenario consist just from creating two JSF pages and sending them simultaneously immediately when the server has just started. As regards the patch, I've just spoken to Rich Kao who is there as an author of the comment and he said he's there by mistake actually, he said he'd just voted for this issue which happened to appear at patch available comment. I'm wondering why no one else is complaining as it seems this issue it must occur quite often. Jakub On 24 August 2010 14:56, Matthias Wessendorf mat...@apache.org wrote: HEllo Jakub, can you update the ticket with how to reproduce? I'll take a look next week (currently on vacation) -M On Tue, Aug 24, 2010 at 2:48 PM, Jakub Kahovec jakub.kaho...@googlemail.com wrote: Hi there, in our application (tomcat 6.0.28+ trinidad 1.2.13+facelets) we are time to time experiencing java.lang.IllegalStateException: Factory already available for this class loader, which seems to be happening when there are two (or more) requests sent very quickly to the server (which IMHO should be pretty normal in busy web apps, right ?) I've found this problem reported in apache JIRA ( https://issues.apache.org/jira/browse/TRINIDAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel ) but there is no solution (it shows that there is a patch is available but it's not there) and the priority was changed from major or minor. Well, this issue seems to me quite critical unless there is something wrong in our settings, which might be likely as I haven't found much references to this issue (actually just one). So has anyone else experienced this problem or is there an easy fix or workaround for it ? Thanks. Jakub -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader
Tried with TRINIDAD-1.2.15-SNAPSHOT (our 12x trunk) + MyFaces 1.2.9 could not reproduce it with the Trinidad demo On Tue, Aug 31, 2010 at 12:12 PM, Matthias Wessendorf mat...@apache.org wrote: Jakub, this does NOT happen on windows, right ? -Matthias On Tue, Aug 24, 2010 at 4:11 PM, Jakub Kahovec jakub.kaho...@googlemail.com wrote: Hi Matthias, thanks for your reply. Well, brief steps how to reproduce this are already in the ticket (not much descriptive though :-). The scenario consist just from creating two JSF pages and sending them simultaneously immediately when the server has just started. As regards the patch, I've just spoken to Rich Kao who is there as an author of the comment and he said he's there by mistake actually, he said he'd just voted for this issue which happened to appear at patch available comment. I'm wondering why no one else is complaining as it seems this issue it must occur quite often. Jakub On 24 August 2010 14:56, Matthias Wessendorf mat...@apache.org wrote: HEllo Jakub, can you update the ticket with how to reproduce? I'll take a look next week (currently on vacation) -M On Tue, Aug 24, 2010 at 2:48 PM, Jakub Kahovec jakub.kaho...@googlemail.com wrote: Hi there, in our application (tomcat 6.0.28+ trinidad 1.2.13+facelets) we are time to time experiencing java.lang.IllegalStateException: Factory already available for this class loader, which seems to be happening when there are two (or more) requests sent very quickly to the server (which IMHO should be pretty normal in busy web apps, right ?) I've found this problem reported in apache JIRA ( https://issues.apache.org/jira/browse/TRINIDAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel ) but there is no solution (it shows that there is a patch is available but it's not there) and the priority was changed from major or minor. Well, this issue seems to me quite critical unless there is something wrong in our settings, which might be likely as I haven't found much references to this issue (actually just one). So has anyone else experienced this problem or is there an easy fix or workaround for it ? Thanks. Jakub -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader
Hi Matthias,
It happens on Windows as well.
After some investigation I found out that the trouble maker is method
org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl#init(javax.faces.context.ExternalContext),
and the critical section is
if (!_initialized)
{
try
{
_services =
ClassLoaderUtils.getServices(Configurator.class.getName());
// Create a new RequestContextFactory is needed
if (RequestContextFactory.getFactory() == null)
{
RequestContextFactory.setFactory(new RequestContextFactoryImpl());
}
// Create a new SkinFactory if needed.
if (SkinFactory.getFactory() == null)
{
SkinFactory.setFactory(new SkinFactoryImpl());
}
which , when two request are being sent simultaneously straight after ther
server has just started, (occasionally) throws the IllegalStateException,
FACTORY_ALREADY_AVAILABLE_FOR_CLASS_LOADER . Either in
RequestContextFactory.setFactory or SkinFactory.setFactory.
I don't have the overall picture of the whole Trinidad architecture, but
just from what I see in the method's code , it seems to me that the
initialization of the factories should be in a synchronized block, using
webapp classloader as a lock.
Jakub
On 31 August 2010 12:38, Matthias Wessendorf mat...@apache.org wrote:
Tried with TRINIDAD-1.2.15-SNAPSHOT (our 12x trunk) + MyFaces 1.2.9
could not reproduce it with the Trinidad demo
On Tue, Aug 31, 2010 at 12:12 PM, Matthias Wessendorf mat...@apache.org
wrote:
Jakub,
this does NOT happen on windows, right ?
-Matthias
On Tue, Aug 24, 2010 at 4:11 PM, Jakub Kahovec
jakub.kaho...@googlemail.com wrote:
Hi Matthias,
thanks for your reply.
Well, brief steps how to reproduce this are already in the ticket (not
much
descriptive though :-). The scenario consist just from
creating two JSF pages and sending them simultaneously immediately when
the
server has just started.
As regards the patch, I've just spoken to Rich Kao who is there as an
author
of the comment and he said he's there by mistake actually, he said he'd
just
voted for this issue which happened to appear at patch available
comment.
I'm wondering why no one else is complaining as it seems this issue it
must
occur quite often.
Jakub
On 24 August 2010 14:56, Matthias Wessendorf mat...@apache.org wrote:
HEllo Jakub,
can you update the ticket with how to reproduce?
I'll take a look next week (currently on vacation)
-M
On Tue, Aug 24, 2010 at 2:48 PM, Jakub Kahovec
jakub.kaho...@googlemail.com wrote:
Hi there,
in our application (tomcat 6.0.28+ trinidad 1.2.13+facelets) we are
time
to
time experiencing java.lang.IllegalStateException: Factory already
available
for this class loader, which
seems to be happening when there are two (or more) requests sent very
quickly to the server (which IMHO should be pretty normal in busy web
apps,
right ?)
I've found this problem reported in apache JIRA (
https://issues.apache.org/jira/browse/TRINIDAD-195?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
)
but there is no solution (it shows that there is a patch is available
but
it's not there) and the priority was changed from major or minor.
Well, this issue seems to me quite critical unless there is something
wrong
in our settings, which might be likely as I haven't found much
references
to
this issue (actually just one).
So has anyone else experienced this problem or is there an easy fix
or
workaround for it ?
Thanks.
Jakub
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: double click problem in JSF
On Tue, Aug 31, 2010 at 3:09 AM, Cédric Durmont cdurm...@gmail.com wrote: Don't try to catch a double-click event. Instead, try to : - catch an onclick event - use it to disable the link - return true, so that this first click will actually do something. The following clicks should not happen because you just disabled/hidden the link Regards Cedric 2010/8/31 yogeen honnavar yog...@yahoo.com: Scott, Yes am also trying javascript solution. but the problem is for h:commandlink onclick event is generated by myfaces. and am not successful at trying to catch double click event also since the form is being submitted even though i catch double click event and say return. can u pls give some code snippet to handle this using javascript. also i read about shale s:token and some other solutions being used to solve this problem. any idea ? regards -yogeen --- On Mon, 30/8/10, Scott O'Bryan darkar...@gmail.com wrote: From: Scott O'Bryan darkar...@gmail.com Subject: Re: double click problem in JSF To: MyFaces Discussion users@myfaces.apache.org Date: Monday, 30 August, 2010, 6:22 PM Yogeen, This is standard link behavior. Short of writing JavaScript to intercept the event and handle double click, here is not much I think you can do. Sent from my iPhone On Aug 29, 2010, at 9:45 PM, yogeen honnavar yog...@yahoo.com wrote: Dear users, We are using myfaces-1.1.5 with tomcat. We have a problem, when a user double clicks on a h:commandlink 2 submissions are sent to the server and hence the application reports an error. Can anybody suggest a solution to the double click problem. regards -yogeen Cedric's solution is a very good one. We use it quite a bit. For help with the syntax, you can use something like this... h:commandButton value=My Button onclick=this.disabled=true; return true; action=... / Donn
ViewExpiredException: MyFaces PrimeFaces
Hi, I'm trying to get PrimeFaces AutoComplete component to work with MyFaces. I have tried with MyFaces 1.2.9 PrimeFaces 1.1, MyFaces 2.0.1 PrimeFaces 2.1 and MyFaces 2.0.1 PrimeFaces 2.2.M1. In the all cases, the fowlloing exception is raised: 31/08/2010 11:51:32 org.apache.myfaces.renderkit.ErrorPageWriter handleThrowable SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /autocomplete.xhtmlNo saved view state could be found for the view identifier: /autocomplete.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) I have created a simple test case (.war): http://www.4shared.com/get/Jm6REAgI/autocomplete.html Any suggestion? Thanks, Rafael Santini
Re: double click problem in JSF
If you do a search for jsf double submit on google, you find a number of hits. The shale or seam token is one possibility if you are already using those frameworks. One here sounded very interesting: == http://forums.sun.com/thread.jspa?threadID=665472 BasheerShaik http://forums.sun.com/profile.jspa?userID=645731 Posts:3 Registered: 8/17/06 * Re: JSF How to prevent double click ? Aug 17, 2006 4:50 PM http://forums.sun.com/thread.jspa?messageID=4345078#4345078 (reply 13 of 47) (In reply to #10 http://forums.sun.com/thread.jspa?messageID=4294753#4294753 ) * == Another possibility, although I haven't read it through: http://jroller.com/mert/entry/jsf_preventing_double_form_submit On Tue, Aug 31, 2010 at 1:33 AM, yogeen honnavar yog...@yahoo.com wrote: Scott, Yes am also trying javascript solution. but the problem is for h:commandlink onclick event is generated by myfaces. and am not successful at trying to catch double click event also since the form is being submitted even though i catch double click event and say return. can u pls give some code snippet to handle this using javascript. also i read about shale s:token and some other solutions being used to solve this problem. any idea ? regards -yogeen --- On Mon, 30/8/10, Scott O'Bryan darkar...@gmail.com wrote: From: Scott O'Bryan darkar...@gmail.com Subject: Re: double click problem in JSF To: MyFaces Discussion users@myfaces.apache.org Date: Monday, 30 August, 2010, 6:22 PM Yogeen, This is standard link behavior. Short of writing JavaScript to intercept the event and handle double click, here is not much I think you can do. Sent from my iPhone On Aug 29, 2010, at 9:45 PM, yogeen honnavar yog...@yahoo.com wrote: Dear users, We are using myfaces-1.1.5 with tomcat. We have a problem, when a user double clicks on a h:commandlink 2 submissions are sent to the server and hence the application reports an error. Can anybody suggest a solution to the double click problem. regards -yogeen
Re: [Tobago] Problem using tc:tree and request parameters
Oh... sorry... I forgot to tell you that your solution has fixed the problem. Many thanks :) Regards, Alf Udo Schnurpfeil schrieb: Hi, Alf, after taking a close look to your problem, we have discovered a problem in the decision if there is a post back, or not. I've added an issue in JIRA: https://issues.apache.org/jira/browse/TOBAGO-905 You may test the current 1.0.x branch or use the nightly build from tomorrow. Regards, Udo Am 25.06.10 09:30, schrieb Alf Felis: Hi Udo, I noticed that the attachments has been removed from my mail. Should I send them to your email account? Regards, Alf -Ursprüngliche Nachricht- Von: Alf Felisalf.fe...@gmx.de Gesendet: 17.06.2010 13:01:43 An: MyFaces Discussionusers@myfaces.apache.org Betreff: Re: [Tobago] Problem using tc:tree and request parameters Hi Udo, sorry... I forgot the environment information: MyFaces 1.1.6 Tobago 1.0.24 and 1.0.27 The bean has session scope. managed-bean managed-bean-nametobagoTreeTestBean/managed-bean-name managed-bean-classTobagoTreeTestBean/managed-bean-class managed-bean-scopesession/managed-bean-scope /managed-bean I have attached my test bean and the jsp page to this mail. First I thought that the request always contains the state of the navigation, but I checked the request parameters (using a servlet filter) and figured out that the state information will only be sent when I click the navigation tree. Nevertheless reloading the page (browser reload) collapses the tree when using parameters and saves the state without using parameters. In both situations there are no request parameters from the navigation state. Request parameters using parameters: Parameters: param: 123 Request parameters without parameters: Parameters: Request parameters when clicking the tree: Parameters: _idJsp0::form-action: _idJsp0:nav:Number1 jsf_tree: 5 _idJsp0::action-position: 0px,0px,0px,0px _idJsp0::context-path: /Tobago jsf_viewid: /TobagoTreeTest.jsp _idJsp0::form-clientDimension: 913;700 _idJsp0:nav: ;Home;Number1; _idJsp0:nav-marker: _idJsp0:nav:Number1 tobago.dummy: _idJsp0:nav-scrollPosition: Regards, Alf -Ursprüngliche Nachricht- Von: Udo Schnurpfeil Gesendet: 17.06.2010 09:59:42 An: MyFaces Discussion Betreff: Re: [Tobago] Problem using tc:tree and request parameters Hi Alf, I've some questions: Which Tobago version and which JSF implementation and version you are using (and which container)? In which scope is the managed bean that holds the state? I don't exactly know what happens, because I've not the sources of you code. But I can try some supposition... The usual usage of Tobago is to write an application, with one or more pages that will be called by clicking on some controls on the page. It was a difference of calling the URL and clicking atc:button. The click on a button will submit the current expansion state of the tree and sends it to the server (via a hidden input field), which manipulates the tree state object. When calling the URL (manually) the expansion state information is not part of the request. When JSF now restores the UIViewRoot and begins to decode the request it clears the expand state and tries to apply the new information from the browser (which are not available in this case). It is correct, that you want to provide external links (non faces request to faces response)? Are you also use internal actions? If not, you don't need to save the expansion state for each user. You can try to put the tree state in the none scope. Regards, Udo Am 15.06.10 15:51, schrieb Alf Felis: Any idea? Original-Nachricht Datum: Thu, 03 Jun 2010 13:31:44 +0200 Von: Alf Felis[ An: MyFaces Discussion Betreff: [Tobago] Problem using tc:tree and request parameters Hi all, I have a problem with tc:tree. In my code I expand the tree after creation using the TreeState: state.expand(tree, 1); This works fine till I use a request parameter... e.g. http://localhost:8080/Tobago/faces/TobagoTreeTest.jsp?param=123 In this case the first/initial call will show an expanded tree... the second call shows a collapsed tree. - first and second call with parameter: - 1.) Call the URL - tree expanded 2.) Reload the URL - tree collapsed - first call with, second without parameter:
Re: ViewExpiredException: MyFaces PrimeFaces
Hi Rafael, Primefaces forum[1] might be a better place to discuss this, but at first sight at your code, you should put the autoCompleteBean in view scope (available with JSF2). [1]http://primefaces.prime.com.tr/forum/ Cheers, Ali On Tue, Aug 31, 2010 at 6:12 PM, SANTINI, Rafael raf...@santini.eti.brwrote: Hi, I'm trying to get PrimeFaces AutoComplete component to work with MyFaces. I have tried with MyFaces 1.2.9 PrimeFaces 1.1, MyFaces 2.0.1 PrimeFaces 2.1 and MyFaces 2.0.1 PrimeFaces 2.2.M1. In the all cases, the fowlloing exception is raised: 31/08/2010 11:51:32 org.apache.myfaces.renderkit.ErrorPageWriter handleThrowable SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /autocomplete.xhtmlNo saved view state could be found for the view identifier: /autocomplete.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) I have created a simple test case (.war): http://www.4shared.com/get/Jm6REAgI/autocomplete.html Any suggestion? Thanks, Rafael Santini -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: ViewExpiredException: MyFaces PrimeFaces
Hi Ali, I have posted this question on PrimeFaces Forum. With Mojarra 1.2_15-b01, works perfectly! The problem is that I need to continue with MyFaces for a while. Thanks, Rafael Santini 2010/8/31 Ali Ok al...@aliok.com.tr Hi Rafael, Primefaces forum[1] might be a better place to discuss this, but at first sight at your code, you should put the autoCompleteBean in view scope (available with JSF2). [1]http://primefaces.prime.com.tr/forum/ Cheers, Ali On Tue, Aug 31, 2010 at 6:12 PM, SANTINI, Rafael raf...@santini.eti.br wrote: Hi, I'm trying to get PrimeFaces AutoComplete component to work with MyFaces. I have tried with MyFaces 1.2.9 PrimeFaces 1.1, MyFaces 2.0.1 PrimeFaces 2.1 and MyFaces 2.0.1 PrimeFaces 2.2.M1. In the all cases, the fowlloing exception is raised: 31/08/2010 11:51:32 org.apache.myfaces.renderkit.ErrorPageWriter handleThrowable SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /autocomplete.xhtmlNo saved view state could be found for the view identifier: /autocomplete.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) I have created a simple test case (.war): http://www.4shared.com/get/Jm6REAgI/autocomplete.html Any suggestion? Thanks, Rafael Santini -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: ViewExpiredException: MyFaces PrimeFaces
Hi Could you check your server log?. A more detailed exception could be found there, to identify easily what's going on. regards, Leonardo Uribe 2010/8/31 Rafael Santini raf...@santini.eti.br Hi Ali, I have posted this question on PrimeFaces Forum. With Mojarra 1.2_15-b01, works perfectly! The problem is that I need to continue with MyFaces for a while. Thanks, Rafael Santini 2010/8/31 Ali Ok al...@aliok.com.tr Hi Rafael, Primefaces forum[1] might be a better place to discuss this, but at first sight at your code, you should put the autoCompleteBean in view scope (available with JSF2). [1]http://primefaces.prime.com.tr/forum/ Cheers, Ali On Tue, Aug 31, 2010 at 6:12 PM, SANTINI, Rafael raf...@santini.eti.br wrote: Hi, I'm trying to get PrimeFaces AutoComplete component to work with MyFaces. I have tried with MyFaces 1.2.9 PrimeFaces 1.1, MyFaces 2.0.1 PrimeFaces 2.1 and MyFaces 2.0.1 PrimeFaces 2.2.M1. In the all cases, the fowlloing exception is raised: 31/08/2010 11:51:32 org.apache.myfaces.renderkit.ErrorPageWriter handleThrowable SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /autocomplete.xhtmlNo saved view state could be found for the view identifier: /autocomplete.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1555) at java.lang.Thread.run(Thread.java:619) I have created a simple test case (.war): http://www.4shared.com/get/Jm6REAgI/autocomplete.html Any suggestion? Thanks, Rafael Santini -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
ViewExpiredException - No saved view state could be found for the view identifier
Hi,
I have been searching for a solution for two days now so I hope you are able
to help me out with the basics!
jdk1.6.0_21, Tomcat 6.0.29, myfaces-core-2.0.1, trinidad-2.0.0-alpha-2 (same
problem before Trinidad), IntelliJ 9
javax.faces.application.ViewExpiredException: /pages/login.xhtmlNo saved
view state could be found for the view identifier: /pages/login.xhtml
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor
.java:128)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:1
71)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127
)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102
)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http
11Protocol.java:588)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
::: faces-config.xml :::
faces-config xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd;
version=2.0
managed-bean
managed-bean-nameloginBean/managed-bean-name
managed-bean-classgpstracer.beans.LoginBean/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
navigation-rule
navigation-case
from-outcomelogin/from-outcome
to-view-id/pages/login.xhtml/to-view-id
redirect/
/navigation-case
navigation-case
from-outcomefrontpage/from-outcome
to-view-id/pages/frontpage.xhtml/to-view-id
redirect/
/navigation-case
/navigation-rule
/faces-config
::: web.xml :::
?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
version=2.5
!-- Context params --
welcome-file-list
welcome-fileindex.xhtml/welcome-file
/welcome-file-list
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.xhtml/url-pattern
/servlet-mapping
/web-app
::: login.xhtml :::
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
body
h:form id=login
h:inputText value=#{loginBean.username}/
h:inputText value=#{loginBean.password}/
h:commandButton action=#{loginBean.login} value=next/
/h:form
/body
/html
::: LoginBean.java :::
public class LoginBean {
private String username;
private String password;
public String login(){
return frontpage;
}
..
..
I load the page by calling index.xhtml or
localhost:8080/faces/pages/login.xhtml.
Hope you can help with this one! Thanks a lot.
-MICAH
Re: PortletBridge starting portlet problem
Did you see the latest e-mail/comment on the thread with the subject line: Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader? Sounds plausible that the lack of synchronization is causing this problem. You can either wait to hear from the Trinidad guys/and hopefully get a patch/fix or try patching the Trinidad code yourself and rebuilding. Let me know me know what you think. By the way it seems a little strange the portal is sending two (simulanteous) requests. Yes portlet 2.0 can have a 2 request render (one to get the headers) and one to get the body -- so maybe its that. But you are using portlet 1.0 (bridge)/portlet 1.0 container. I wonder if uPortal has a bug where the portal itself knows about portlet 2.0 but isn't smart enough to detect the container is 1.0 so sends the double render request (one to get the headers and the other to get the body) as they only differ from a request perspective by a flag in the request? Anyway if this is the problem and you were running in a portlet 2.0 container you could check for this flag in a subclass of the GenericFacesPortlet and when set to Header merely return without delegating to the bridge. But since you are running in a 1.0 container I have no clue. -Mike- On 8/30/2010 8:39 AM, Yves Deschamps wrote: It means Factory already available for this class loader Thanks... Scott O'Bryan a écrit : Yay.. Exception translation at work. Yves, can you tell us what that message states in English? Sorry, half the characters didn't come through. Sent from my iPhone On Aug 30, 2010, at 6:50 AM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: Hi Michael, I just come back from holidays. I try my app with this environment: trinidad 1.2.15-SNAPSHOT (30/08/2010) portlet-bridge 1.0.0 (distribution) myfaces 1.2.9 (distribution) portlet-api-1.0 pluto... 1.1.7 uPortal-3.2.1 The result is : Caused by: java.lang.IllegalStateException: Factory d�j� disponible pour ce chargeur de classe. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.lt;initgt;(FacesContextFactoryImpl.java:86) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.getFacesContext(BridgeImpl.java:943) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:513) And when the portlet is refreshed, all is ok ! I see this recent message in the list: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader, I think that the portal make a double request to the portlet ? May be can you test my app in your environment with this zip file : https://bigfile.univ-lille1.fr/get?k=QxI6pCDOMWM12k0bTdJ Thank you in advance. Michael Freedman a �crit : This feels more environmental than anything else. Is this still just the situation when accessing from an iPhone user-agent? The regular user-agent still works fine? Can you send me a complete description of your environment? I.e. Specific Trinidad version, Faces make (Mojarra or Myfaces?) and version, appserver version which includes portlet container make (pluto ???) and version? What has me stumped here is that the line you indicate is throwing the null pointer exception: switch ((Bridge.PortletPhase) mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE)) The instance is constructed with the requestObject which is passed by the bridge's externalContext which gets it in its constructor -- so unless a release() occurred I don't see how its null. Likewise the bridge's doFacesRender (further down the stack) has already set the request attribute we are looking for here -- which means it should be around unless a spurious release occurred. We have encountered problems releasing attributes in some servers which the portal server/container is treating specially because of their prefix like javax.* -- but I haven't seen any issues in setting/retrieving. So first thing we need to do is figure out what is causing the NPE. Is the request in fact null here? Or the attribute not there? (My bet is on the later). And if the later, why it isn't there as its clearly been set. Are you able to do some debugging to answer some of these questions? If not let me know as i can build you one-of bridge jars that will write extra info to the logs to get us
Re: PortletBridge starting portlet problem
I doubt it's a synchronization issue since the Factory is complaining that it already exists for a particular thread. That to me seems to imply it's single threaded. Sent from my iPhone On Aug 31, 2010, at 3:52 PM, Michael Freedman michael.freed...@oracle.com wrote: Did you see the latest e-mail/comment on the thread with the subject line: Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader? Sounds plausible that the lack of synchronization is causing this problem. You can either wait to hear from the Trinidad guys/and hopefully get a patch/fix or try patching the Trinidad code yourself and rebuilding. Let me know me know what you think. By the way it seems a little strange the portal is sending two (simulanteous) requests. Yes portlet 2.0 can have a 2 request render (one to get the headers) and one to get the body -- so maybe its that. But you are using portlet 1.0 (bridge)/portlet 1.0 container. I wonder if uPortal has a bug where the portal itself knows about portlet 2.0 but isn't smart enough to detect the container is 1.0 so sends the double render request (one to get the headers and the other to get the body) as they only differ from a request perspective by a flag in the request? Anyway if this is the problem and you were running in a portlet 2.0 container you could check for this flag in a subclass of the GenericFacesPortlet and when set to Header merely return without delegating to the bridge. But since you are running in a 1.0 container I have no clue. -Mike- On 8/30/2010 8:39 AM, Yves Deschamps wrote: It means Factory already available for this class loader Thanks... Scott O'Bryan a �crit : Yay.. Exception translation at work. Yves, can you tell us what that message states in English? Sorry, half the characters didn't come through. Sent from my iPhone On Aug 30, 2010, at 6:50 AM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: Hi Michael, I just come back from holidays. I try my app with this environment: trinidad 1.2.15-SNAPSHOT (30/08/2010) portlet-bridge 1.0.0 (distribution) myfaces 1.2.9 (distribution) portlet-api-1.0 pluto... 1.1.7 uPortal-3.2.1 The result is : Caused by: java.lang.IllegalStateException: Factory d�j� disponible pour ce chargeur de classe. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.lt;initgt;(FacesContextFactoryImpl.java:86) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.getFacesContext(BridgeImpl.java:943) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:513) And when the portlet is refreshed, all is ok ! I see this recent message in the list: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader, I think that the portal make a double request to the portlet ? May be can you test my app in your environment with this zip file : https://bigfile.univ-lille1.fr/get?k=QxI6pCDOMWM12k0bTdJ Thank you in advance. Michael Freedman a �crit : This feels more environmental than anything else. Is this still just the situation when accessing from an iPhone user-agent? The regular user-agent still works fine? Can you send me a complete description of your environment? I.e. Specific Trinidad version, Faces make (Mojarra or Myfaces?) and version, appserver version which includes portlet container make (pluto ???) and version? What has me stumped here is that the line you indicate is throwing the null pointer exception: switch ((Bridge.PortletPhase) mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE)) The instance is constructed with the requestObject which is passed by the bridge's externalContext which gets it in its constructor -- so unless a release() occurred I don't see how its null. Likewise the bridge's doFacesRender (further down the stack) has already set the request attribute we are looking for here -- which means it should be around unless a spurious release occurred. We have encountered problems releasing attributes in some servers which the portal server/container is treating specially because of their prefix like javax.* -- but I haven't seen any issues in setting/retrieving. So first thing we need to do is figure out what is causing the NPE. Is the request in fact
Re: PortletBridge starting portlet problem
Never mind. My pneumonia is effecting my brain.. :) sorry. Let me take a look at this tomorrow when I'm hopefully not running a fever. Sent from my iPhone On Aug 31, 2010, at 4:41 PM, Scott O'Bryan darkar...@gmail.com wrote: I doubt it's a synchronization issue since the Factory is complaining that it already exists for a particular thread. That to me seems to imply it's single threaded. Sent from my iPhone On Aug 31, 2010, at 3:52 PM, Michael Freedman michael.freed...@oracle.com wrote: Did you see the latest e-mail/comment on the thread with the subject line: Re: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader? Sounds plausible that the lack of synchronization is causing this problem. You can either wait to hear from the Trinidad guys/and hopefully get a patch/fix or try patching the Trinidad code yourself and rebuilding. Let me know me know what you think. By the way it seems a little strange the portal is sending two (simulanteous) requests. Yes portlet 2.0 can have a 2 request render (one to get the headers) and one to get the body -- so maybe its that. But you are using portlet 1.0 (bridge)/portlet 1.0 container. I wonder if uPortal has a bug where the portal itself knows about portlet 2.0 but isn't smart enough to detect the container is 1.0 so sends the double render request (one to get the headers and the other to get the body) as they only differ from a request perspective by a flag in the request? Anyway if this is the problem and you were running in a portlet 2.0 container you could check for this flag in a subclass of the GenericFacesPortlet and when set to Header merely return without delegating to the bridge. But since you are running in a 1.0 container I have no clue. -Mike- On 8/30/2010 8:39 AM, Yves Deschamps wrote: It means Factory already available for this class loader Thanks... Scott O'Bryan a �crit : Yay.. Exception translation at work. Yves, can you tell us what that message states in English? Sorry, half the characters didn't come through. Sent from my iPhone On Aug 30, 2010, at 6:50 AM, Yves Deschamps yves.descha...@univ-lille1.fr wrote: Hi Michael, I just come back from holidays. I try my app with this environment: trinidad 1.2.15-SNAPSHOT (30/08/2010) portlet-bridge 1.0.0 (distribution) myfaces 1.2.9 (distribution) portlet-api-1.0 pluto... 1.1.7 uPortal-3.2.1 The result is : Caused by: java.lang.IllegalStateException: Factory d�j� disponible pour ce chargeur de classe. at org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.lt;initgt;(FacesContextFactoryImpl.java:86) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.getFacesContext(BridgeImpl.java:943) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:513) And when the portlet is refreshed, all is ok ! I see this recent message in the list: [Trinidad] java.lang.IllegalStateException: Factory already available for this class loader, I think that the portal make a double request to the portlet ? May be can you test my app in your environment with this zip file : https://bigfile.univ-lille1.fr/get?k=QxI6pCDOMWM12k0bTdJ Thank you in advance. Michael Freedman a �crit : This feels more environmental than anything else. Is this still just the situation when accessing from an iPhone user-agent? The regular user-agent still works fine? Can you send me a complete description of your environment? I.e. Specific Trinidad version, Faces make (Mojarra or Myfaces?) and version, appserver version which includes portlet container make (pluto ???) and version? What has me stumped here is that the line you indicate is throwing the null pointer exception: switch ((Bridge.PortletPhase) mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE)) The instance is constructed with the requestObject which is passed by the bridge's externalContext which gets it in its constructor -- so unless a release() occurred I don't see how its null. Likewise the bridge's doFacesRender (further down the stack) has already set the request attribute we are looking for here -- which means it should be around unless a spurious release occurred. We have encountered problems releasing attributes in some servers which
