Re: org.apache.myfaces.ERROR_HANDLER with portlet-bridge
Hi Michael,
The goal is to simulate an exception, intercept it and make somethings
like e-mail to application administrator, an exception page, etc...
Since my last e-mail, I progressed.
I use that:
facelets.DEVELOPMENT
true
and that..
org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER
org.esupportail.blank.web.jsf.mixed.FaceletRedirectionViewHandler
This last class extends com.sun.facelets.FaceletViewHandler, but the
result is not convincing...
Is it better to use com.sun.facelets.FaceletPortletViewHandler ?
Le 07/03/2011 22:44, Michael Freedman a écrit :
No idea -- as this is an error rendering a resource accessed via http
(i.e. not through the portlet -- but as a consequence of rendering a
portlet). Obviously there is an issue with the preferencesController
managed bean. What scope is it at? Can you set a breakpoint in
geet/set localeItems and try and see what is happening? Can you also
send the whole stack so we can see if there is any useful information
in it?
-Mike-
On 3/3/2011 7:40 AM, Yves Deschamps wrote:
Hi Scott
Trinidad 1.2.14 and portlet-bridge 1.0.0 (JSR 168)...
Le 03/03/2011 16:32, Scott O'Bryan a écrit :
Trinidad 1.2 and the latest Portlet Bridge 2.0 I assume?
On Mar 3, 2011, at 8:29 AM, Yves Deschamps
wrote:
Hi,
I try to use org.apache.myfaces.ERROR_HANDLER with apache
porlet-bridge and my own error handling class .
But that does not work.
It is ok in servlet mode.
In portlet mode, the exception is handled like this...
3 mars 2011 16:16:14 com.sun.facelets.FaceletViewHandler
handleRenderException
GRAVE: Error Rendering View[/stylesheets/desktop/preferences.xhtml]
javax.el.ELException: /stylesheets/desktop/preferences.xhtml @10,79
value="#{preferencesController.localeItems}": Error reading
'localeItems' on type
org.esupportail.blank.web.controllers.PreferencesController
An idea ?
--
Yves Deschamps
CRI P�le Web, Environnement Num�rique de Travail
B�timent M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Blog Pro : http://blogs.univ-lille1.fr/pg/blog/ydescham
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Blog Pro : http://blogs.univ-lille1.fr/pg/blog/ydescham
Re: org.apache.myfaces.ERROR_HANDLER with portlet-bridge
Hi Scott
Trinidad 1.2.14 and portlet-bridge 1.0.0 (JSR 168)...
Le 03/03/2011 16:32, Scott O'Bryan a écrit :
Trinidad 1.2 and the latest Portlet Bridge 2.0 I assume?
On Mar 3, 2011, at 8:29 AM, Yves Deschamps
wrote:
Hi,
I try to use org.apache.myfaces.ERROR_HANDLER with apache porlet-bridge and my
own error handling class .
But that does not work.
It is ok in servlet mode.
In portlet mode, the exception is handled like this...
3 mars 2011 16:16:14 com.sun.facelets.FaceletViewHandler handleRenderException
GRAVE: Error Rendering View[/stylesheets/desktop/preferences.xhtml]
javax.el.ELException: /stylesheets/desktop/preferences.xhtml @10,79
value="#{preferencesController.localeItems}": Error reading 'localeItems' on
type org.esupportail.blank.web.controllers.PreferencesController
An idea ?
--
Yves Deschamps
CRI P�le Web, Environnement Num�rique de Travail
B�timent M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Blog Pro : http://blogs.univ-lille1.fr/pg/blog/ydescham
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Blog Pro : http://blogs.univ-lille1.fr/pg/blog/ydescham
org.apache.myfaces.ERROR_HANDLER with portlet-bridge
Hi,
I try to use org.apache.myfaces.ERROR_HANDLER with apache porlet-bridge
and my own error handling class .
But that does not work.
It is ok in servlet mode.
In portlet mode, the exception is handled like this...
3 mars 2011 16:16:14 com.sun.facelets.FaceletViewHandler
handleRenderException
GRAVE: Error Rendering View[/stylesheets/desktop/preferences.xhtml]
javax.el.ELException: /stylesheets/desktop/preferences.xhtml @10,79
value="#{preferencesController.localeItems}": Error reading
'localeItems' on type
org.esupportail.blank.web.controllers.PreferencesController
An idea ?
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Blog Pro : http://blogs.univ-lille1.fr/pg/blog/ydescham
Re: TRinidad + Portlet-Bridge ViewExpired in Internet Explorer
Thank you all, The problem is now resolved. In fact I use the first page " home.jsf " which activates an action (a javascript which presses on a button) and thus passes in " / stylesheets / desktop / welcome.jsf " if I am in "desktop" mode or " / stylesheets / mobile / welcome.jsf " if I am in "mobile" mode. The fact of indicating " < redirect / > " in "navigation-rules" resolved my problem. I hope not to have made you lose too much time. Le 27/10/2010 22:48, Michael Freedman a écrit : Can you give us some additional details? 1. Can you confirm that /stylesheets/desktop/welcome.jsf is a valid viewId/view you have provided in the app? I.e. its not a resource/stylesheet referenced in the markup of a view? 2. Describe the various steps you take before this problem occurs ... something like: * Hit portal page: portlet renders view /.jsf * Invoke action in portlet results in rendering view /.jsf * At this point I (do something?/do nothing?) in then shortly the (page?/portlet?) auto rerenders and generates the error message. 3. Does this problem only occur in uPortal? I.e. since uPortal seems to use the pluto portlet container can you reproduce on Apache Pluto? 4. Have you enabled trace logging in Faces? If not can you? Can you send me the logged results? 5. Can you reproduce in a simplified test case that you can submit with a JIRA bug? -Mike- On 10/26/2010 12:16 AM, Yves Deschamps wrote: I am using IE 8.0 Faces 1.2.9 Portlet-Bridge 1.0.0 Trinidad 1.2.13 uPortal 3.1.2 Thanks Le 25/10/2010 23:00, Scott O'Bryan a écrit : Which version of IE, Faces, Bridge, and Trinidad are you using? On 10/25/2010 10:17 AM, Yves Deschamps wrote: Hi All, I have this issue in IE, not in Firefox ? The portlet it's Ok but a few seconds later, it's down without action ! javax.faces.application.ViewExpiredException: /stylesheets/desktop/welcome.jsfNo saved view state could be found for the view identifier: /stylesheets/desktop/welcome.jsf at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:636) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:553) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:197) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:607) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27) at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framewo
Re: TRinidad + Portlet-Bridge ViewExpired in Internet Explorer
I am using IE 8.0 Faces 1.2.9 Portlet-Bridge 1.0.0 Trinidad 1.2.13 uPortal 3.1.2 Thanks Le 25/10/2010 23:00, Scott O'Bryan a écrit : Which version of IE, Faces, Bridge, and Trinidad are you using? On 10/25/2010 10:17 AM, Yves Deschamps wrote: Hi All, I have this issue in IE, not in Firefox ? The portlet it's Ok but a few seconds later, it's down without action ! javax.faces.application.ViewExpiredException: /stylesheets/desktop/welcome.jsfNo saved view state could be found for the view identifier: /stylesheets/desktop/welcome.jsf at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:636) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:553) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:197) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:607) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27) at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at org.jasig.portal.$Proxy60.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
TRinidad + Portlet-Bridge ViewExpired in Internet Explorer
Hi All, I have this issue in IE, not in Firefox ? The portlet it's Ok but a few seconds later, it's down without action ! javax.faces.application.ViewExpiredException: /stylesheets/desktop/welcome.jsfNo saved view state could be found for the view identifier: /stylesheets/desktop/welcome.jsf at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:636) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:553) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:197) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:607) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27) at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at org.jasig.portal.$Proxy60.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: PortletBridge starting portlet problem
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 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.<init>(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 org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMap.java:38) at org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMa
Re: PortletBridge starting portlet problem
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.<init>(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 org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMap.java:38) at org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMap.java:26) at org.apache.myfaces.portlet.faces.util.map.PortletAbstractMap.get(PortletAbstractMap.java:88) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.isAjaxRequest(CoreRenderKit.java:148) at org.apache.myfaces.trinidadinternal.renderkit.core.C
Re: PortletBridge starting portlet problem
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
org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMap.java:38)
at
org.apache.myfaces.portlet.faces.util.map.PortletRequestHeaderMap.getAttribute(PortletRequestHeaderMap.java:26)
at
org.apache.myfaces.portlet.faces.util.map.PortletAbstractMap.get(PortletAbstractMap.java:88)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.isAjaxRequest(CoreRenderKit.java:148)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.isPartialRequest(CoreRenderKit.java:163)
at
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator.getExternalContext(XmlHttpConfigurator.java:61)
at
org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:353)
at
org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.(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)
So:
1) the portletBridge needs a FacesContext from trinidad...
2) trinidad needs an element from external context:
static public boolean isAjaxRequest(ExternalContext ec)
{
return "true".equals(ec.getRequestHeaderMap().get(_PPR_REQUEST_HEADER));
}
3) the portletBridge fails to return this boolean:
// can't assume portlet container overrides these headers to reflect
portlet constraints -- so do so
ensurePortletAcceptHeader();
ensurePortletAcceptLanguage();
switch ((Bridge.PortletPhase)
mPortletRequest.getAttribute(Bridge.PORTLET_LIFECYCLE_PHASE))
---
May be, have I missed something in config files ?
I think there is something wrong between "trinidad" and "portletBridge"...
Michael Freedman a écrit :
Looks like its failing in this line in Trinidad:
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.getRenderKit(RenderKitDecorator.java:119)
ConcurrentMap appMap =
RequestContext.getCurrentInstance().getApplicationScopedConcurrentMap();
Which means, I assume, that RequestContext.getCurrentInstance() is
returning null. I don't have any idea why this might happen in a
portlet/iPhone environment but maybe you can psuh on the Trinidad
folks to help or maybe this gives you an idea on where/how to
investigate.
-Mike-
On 7/7/2010 12:34 AM, Yves Deschamps wrote:
Thank you Michael,
May be it is a track...
My portlet is written in JSF 1.2 with Trinidad.
When I am in "Default" User Agent, no problem.
When I am in "iPhone" User Agent, the portlet don't start fine.
I see tht in logs :
org.jasig.portal.channels.portlet.PortletDispatchException: Exception
executing portlet RenderRequest: [channelPublishId=84,
channelSubscribeId=n381, portletApplicationId=/esup-news-mobile,
portletName=EsupNewsMobilePortlet, user=admin]
at
org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:380)
at
org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:217)
at
org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:631)
at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:41)
at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at
org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at org.jasig.portal.$Proxy106.run(Unknown Source)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
a
Re: PortletBridge starting portlet problem
40 more Michael Freedman a écrit : Hum... This is what I see for line 428 (BridgeImpl.doFacesRequest(BridgeImpl.java:428): if (request.getPortletSession().getAttribute(key) == null) As the request object has already been dereferenced before this line, the only way, that I can see, that this can throw a NullPointerException is if getPortletSession is returning null -- however by (Portlet) spec this isn't expected as this call should automatically create a session if one doesn't exist. And given that you seem to be running on a version of Pluto (which in other environments behaves correctly) its a mystery. Sounds like this one will take a little debugging. Can you either grab the sources for the version of pluto (and the bridge) and debug into this and send more information? Or can you package up the entire environment (portal/appserver, etc) as a zip and send it to me? If you do this later I need to know the specific version of pluto being used so I can pull/debug with the appropriate sources. -Mike- On 7/6/2010 5:39 AM, Yves Deschamps wrote: Hi all, I have this exception when the portlet start... An idea ? GRAVE: "Servlet.service()" pour la servlet esup-news-mobile a lancé une exception java.lang.NullPointerException at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:428) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.portlet.rendering.PortletRendererImpl.doRender(PortletRendererImpl.java:232) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:376) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:217) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:631) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:41) at sun.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at org.jasig.portal.$Proxy106.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: PortletBridge starting portlet problem
Hi Scott, Yes i have a default viewId in portlet.xml : javax.portlet.faces.defaultViewId.view /home.jsp I am using this version (with good help from Michael Freedman). http://people.apache.org/~mfreedman/portlet-bridge/ Scott O'Bryan a écrit : I don't have time to take a look at the line ring now but do you have a default viewId specified? Also, what version of the bridge are you using? Sent from my iPhone On Jul 6, 2010, at 6:39 AM, Yves Deschamps wrote: Hi all, I have this exception when the portlet start... An idea ? GRAVE: "Servlet.service()" pour la servlet esup-news-mobile a lanc� une exception java.lang.NullPointerException at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:428) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.portlet.rendering.PortletRendererImpl.doRender(PortletRendererImpl.java:232) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:376) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:217) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:631) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:41) at sun.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at org.jasig.portal.$Proxy106.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- Yves Deschamps CRI P�le Web, Environnement Num�rique de Travail B�timent M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25 -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
PortletBridge starting portlet problem
Hi all, I have this exception when the portlet start... An idea ? GRAVE: "Servlet.service()" pour la servlet esup-news-mobile a lancé une exception java.lang.NullPointerException at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:428) at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) at org.jasig.portal.portlet.rendering.PortletRendererImpl.doRender(PortletRendererImpl.java:232) at org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:376) at org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:217) at org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:631) at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:41) at sun.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.orm.jpa.JpaInterceptor.invoke(JpaInterceptor.java:96) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at org.jasig.portal.$Proxy106.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: Trinidad PortletBridge buttons don't work fine
Thank you very much Michael.
Finaly i try your last distrib
(http://people.apache.org/~mfreedman/portlet-bridge/ ) and all is OK.
The portal is uPortal 3.2.1
I am very happy !
Michael Freedman a écrit :
I wonder if this problem is the same as PORTLETBRIDGE-100
<https://issues.apache.org/jira/browse/PORTLETBRIDGE-100>
(https://issues.apache.org/jira/browse/PORTLETBRIDGE-100):
The first page of the JSF sample CarDemo has you set the locale for
the demo. You choose a language/region and the rest of the views use
strings earmarked for the language of the locale. In the portlet
case this fails -- you always use the English/default locale. This
is because the demo relies on an ActionHandler to set the locale of
the ViewRoot of the current view -- which subsequently is migrated
(by Faces) during the createView of the view the action handler
navigates to. When you render the subsequent view it uses this
locale. In the portlet case because render happens in a separate
request -- we rely on the bridge to cache the viewroot from the end
of the action and preset set it as the current viewRoot prior to
running the lifecycle. Well Faces has code in its restoreView phase
that if the ViewRoot was preset then it resets its locale to the
preferred one from the current request. I.e. we lose the locale we
wanted (that was set when the view was created at the end of the
action). To fix this, cache the locale in the beforePhase (of
restoreView) if using the preset ViewRoot and restore it in the
afterPhase.
What version of the bridge are you using? If P1.0B and its beta (or
before) then the above bug exists (or P2.0B alpha and before).
Anyway, I would suggest retrying with a new(er) bridge. Either build
from the trunk, wait a few days as we are in the processing of pushing
the 1.0.0 release, or grab what we are pushing from our staged
artifacts at:
http://people.apache.org/~mfreedman/portlet-bridge/
Let me know if this fixes it. If it doesn't please log a JIRA which
includes additional information describing the appserver and portal
server/container you are using, specific version information for all,
and (if possible) a small sample JSF app I can "portletize" so I can
deploy locally and debug.
-Mike-
On 7/1/2010 8:37 AM, Yves Deschamps wrote:
Hi at all,
I have this view and this methods in controller , all is fine in
servlet mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the "reset" change also the locale (in "en" where i am in "fr")
without sense for me.
---
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad/html"; prefix="trh"%>
type="text/css" />
text="#{msg['DIRECTORY.TEXT']}">
text="#{msg['CANCEL.TEXT']}"
actionListener="#{commonController.reset}" />
rendered="#{not commonController.userAuthenticated
and not commonController.portletMode}"
immediate="true" />
rendered="#{commonController.userAuthenticated and
not commonController.portletMode}"
immediate="true" />
actionListener="#{commonController.setLocaleFrench}" immediate="true" />
actionListener="#{commonController.setLocaleEnglish}"
immediate="true" />
value="#{msg['USER.TEXT']} #{commonController.user}"
rendered="#{commonController.userAuthenticated and not
commonController.portletMode}" />
value="#{commonController.name}" required="true" label="">
action="persons" />
action="students"
rendered="#{commonController.userAuthenticated}" />
action="entities" />
destination="#{commonController.facultyWebPageUrl}" />
-
/**
* @param actionEvent
* @return navigation String.
*/
public String setLocaleFrench(ActionEvent actionEvent) {
FacesContext context = FacesConte
Re: Trinidad PortletBridge buttons don't work fine
Sorry, i change the code with no effect...
public void beforePhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
cacheLocale = context.getViewRoot().getLocale();
}
public void afterPhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(cacheLocale);
}
Yves Deschamps a écrit :
Thank you Michael,
I try this:
beforePhase="#{commonController.beforePhase}"
afterPhase="#{commonController.afterPhase}">
and:
public void beforePhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
cacheLocale = context.getViewRoot().getLocale().getCountry();
}
public void afterPhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale(cacheLocale));
}
With no effect... Have I made an error?
Michael Freedman a écrit :
I wonder if this problem is the same as PORTLETBRIDGE-100
<https://issues.apache.org/jira/browse/PORTLETBRIDGE-100>
(https://issues.apache.org/jira/browse/PORTLETBRIDGE-100):
The first page of the JSF sample CarDemo has you set the locale for
the demo. You choose a language/region and the rest of the views use
strings earmarked for the language of the locale. In the portlet
case this fails -- you always use the English/default locale. This
is because the demo relies on an ActionHandler to set the locale of
the ViewRoot of the current view -- which subsequently is migrated
(by Faces) during the createView of the view the action handler
navigates to. When you render the subsequent view it uses this
locale. In the portlet case because render happens in a separate
request -- we rely on the bridge to cache the viewroot from the end
of the action and preset set it as the current viewRoot prior to
running the lifecycle. Well Faces has code in its restoreView phase
that if the ViewRoot was preset then it resets its locale to the
preferred one from the current request. I.e. we lose the locale we
wanted (that was set when the view was created at the end of the
action). To fix this, cache the locale in the beforePhase (of
restoreView) if using the preset ViewRoot and restore it in the
afterPhase.
What version of the bridge are you using? If P1.0B and its beta (or
before) then the above bug exists (or P2.0B alpha and before).
Anyway, I would suggest retrying with a new(er) bridge. Either build
from the trunk, wait a few days as we are in the processing of
pushing the 1.0.0 release, or grab what we are pushing from our
staged artifacts at:
http://people.apache.org/~mfreedman/portlet-bridge/
Let me know if this fixes it. If it doesn't please log a JIRA which
includes additional information describing the appserver and portal
server/container you are using, specific version information for all,
and (if possible) a small sample JSF app I can "portletize" so I can
deploy locally and debug.
-Mike-
On 7/1/2010 8:37 AM, Yves Deschamps wrote:
Hi at all,
I have this view and this methods in controller , all is fine in
servlet mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the "reset" change also the locale (in "en" where i am in "fr")
without sense for me.
---
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad/html"; prefix="trh"%>
type="text/css" />
text="#{msg['DIRECTORY.TEXT']}">
text="#{msg['CANCEL.TEXT']}"
actionListener="#{commonController.reset}" />
rendered="#{not
commonController.userAuthenticated and not
commonController.portletMode}"
immediate="true" />
rendered="#{commonController.userAuthenticated
and not commonController.portletMode}"
immediate="true" />
actionListener="#{commonController.setLocaleFrench}"
immediate="true" />
actionListener="#{commonController.setLocaleEnglish}"
immediate="true" />
value="#{msg['USER.TEXT']} #{commonController.user}"
rendered="#{commonCon
Re: Trinidad PortletBridge buttons don't work fine
Thank you Michael,
I try this:
beforePhase="#{commonController.beforePhase}"
afterPhase="#{commonController.afterPhase}">
and:
public void beforePhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
cacheLocale = context.getViewRoot().getLocale().getCountry();
}
public void afterPhase(PhaseEvent phase) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale(cacheLocale));
}
With no effect... Have I made an error?
Michael Freedman a écrit :
I wonder if this problem is the same as PORTLETBRIDGE-100
<https://issues.apache.org/jira/browse/PORTLETBRIDGE-100>
(https://issues.apache.org/jira/browse/PORTLETBRIDGE-100):
The first page of the JSF sample CarDemo has you set the locale for
the demo. You choose a language/region and the rest of the views use
strings earmarked for the language of the locale. In the portlet
case this fails -- you always use the English/default locale. This
is because the demo relies on an ActionHandler to set the locale of
the ViewRoot of the current view -- which subsequently is migrated
(by Faces) during the createView of the view the action handler
navigates to. When you render the subsequent view it uses this
locale. In the portlet case because render happens in a separate
request -- we rely on the bridge to cache the viewroot from the end
of the action and preset set it as the current viewRoot prior to
running the lifecycle. Well Faces has code in its restoreView phase
that if the ViewRoot was preset then it resets its locale to the
preferred one from the current request. I.e. we lose the locale we
wanted (that was set when the view was created at the end of the
action). To fix this, cache the locale in the beforePhase (of
restoreView) if using the preset ViewRoot and restore it in the
afterPhase.
What version of the bridge are you using? If P1.0B and its beta (or
before) then the above bug exists (or P2.0B alpha and before).
Anyway, I would suggest retrying with a new(er) bridge. Either build
from the trunk, wait a few days as we are in the processing of pushing
the 1.0.0 release, or grab what we are pushing from our staged
artifacts at:
http://people.apache.org/~mfreedman/portlet-bridge/
Let me know if this fixes it. If it doesn't please log a JIRA which
includes additional information describing the appserver and portal
server/container you are using, specific version information for all,
and (if possible) a small sample JSF app I can "portletize" so I can
deploy locally and debug.
-Mike-
On 7/1/2010 8:37 AM, Yves Deschamps wrote:
Hi at all,
I have this view and this methods in controller , all is fine in
servlet mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the "reset" change also the locale (in "en" where i am in "fr")
without sense for me.
---
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad/html"; prefix="trh"%>
type="text/css" />
text="#{msg['DIRECTORY.TEXT']}">
text="#{msg['CANCEL.TEXT']}"
actionListener="#{commonController.reset}" />
rendered="#{not commonController.userAuthenticated
and not commonController.portletMode}"
immediate="true" />
rendered="#{commonController.userAuthenticated and
not commonController.portletMode}"
immediate="true" />
actionListener="#{commonController.setLocaleFrench}" immediate="true" />
actionListener="#{commonController.setLocaleEnglish}"
immediate="true" />
value="#{msg['USER.TEXT']} #{commonController.user}"
rendered="#{commonController.userAuthenticated and not
commonController.portletMode}" />
value="#{commonController.name}" required="true" label="">
action="persons" />
action="students"
rendered="#{commonController.userAuthenticated}" /&g
Trinidad PortletBridge buttons don't work fine
Hi at all,
I have this view and this methods in controller , all is fine in servlet
mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the "reset" change also the locale (in "en" where i am in "fr")
without sense for me.
---
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr"%>
<%@ taglib uri="http://myfaces.apache.org/trinidad/html"; prefix="trh"%>
type="text/css" />
text="#{msg['DIRECTORY.TEXT']}">
text="#{msg['CANCEL.TEXT']}"
actionListener="#{commonController.reset}" />
rendered="#{not commonController.userAuthenticated
and not commonController.portletMode}"
immediate="true" />
rendered="#{commonController.userAuthenticated and
not commonController.portletMode}"
immediate="true" />
actionListener="#{commonController.setLocaleFrench}"
immediate="true" />
actionListener="#{commonController.setLocaleEnglish}" immediate="true" />
rendered="#{commonController.userAuthenticated and not
commonController.portletMode}" />
required="true" label="">
action="persons" />
action="students"
rendered="#{commonController.userAuthenticated}" />
action="entities" />
-
/**
* @param actionEvent
* @return navigation String.
*/
public String setLocaleFrench(ActionEvent actionEvent) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale("fr"));
locale = "fr";
logger.info("Language: fr");
return "home";
}
/**
* @param actionEvent
* @return navigation String.
*/
public String setLocaleEnglish(ActionEvent actionEvent) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale("en"));
locale = "en";
logger.info("Language: en");
return "home";
}
/**
* @return the locale
*/
public String getLocale() {
return locale;
}
/**
* @param actionEvent
* @return navigation String.
*/
public String reset(ActionEvent actionEvent) {
name = null;
logger.info("Action: reset");
return "home";
}
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Re: Portletbride and Trinidad skin not found
Hi, I solve my problem with this defintition skin: iphone iphoneFamily *portlet* /iPhone/iPhonePortlet.css Yves Deschamps a écrit : Thank's Scott My english is also very bad :-) When my application detect good User-Agent and goodFamily But jsf trinidad in portlet mode don't find the skin... I try that iphone.portlet iphoneFamily org.apache.myfaces.trinidad.desktop iPhone/iPhone.css or that iphone.portlet iphoneFamily org.apache.myfaces.trinidad.portlet iPhone/iPhone.css but no result ! I think org.apache.myfaces.trinidad.portlet is not implemented :-\ Scott O'Bryan a écrit : Yves, The portal skins have some special styling. I don't know french very well, but it's possible that you're trying to use a skin that is not based on simple or doesn't have an equivalent in the portal. Trinidad was reskinned a while back and I'm not sure I ever checked it for portal compatibilith. Can ypi confirm what skin you are using and I'll try to generate a Jira ticket to get this fixed? Scott On Friday, June 11, 2010, Yves Deschamps wrote: Oups, the attached file is lost... I have that: 10 juin 2010 18:15:39 org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl getSkin ATTENTION: Impossible de trouver une apparence correspondant à la famille minimalFamily et au kit renderkit portlet. Utilisation de l'apparence simple Thank's Yves Deschamps a écrit : Here is my tomcat screen (attached file). Michael Freedman a écrit : Can you provide more information? What specific warnings are you seeing? Anything else? On 6/10/2010 6:50 AM, Yves Deschamps wrote: Hi, My JSF Trinidad application (servlet) run. But in portlet mode the skins are not found (warning message)... An idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25 -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: Portletbride and Trinidad skin not found
Thank's Scott My english is also very bad :-) When my application detect good User-Agent and goodFamily But jsf trinidad in portlet mode don't find the skin... I try that iphone.portlet iphoneFamily org.apache.myfaces.trinidad.desktop iPhone/iPhone.css or that iphone.portlet iphoneFamily org.apache.myfaces.trinidad.portlet iPhone/iPhone.css but no result ! I think org.apache.myfaces.trinidad.portlet is not implemented :-\ Scott O'Bryan a écrit : Yves, The portal skins have some special styling. I don't know french very well, but it's possible that you're trying to use a skin that is not based on simple or doesn't have an equivalent in the portal. Trinidad was reskinned a while back and I'm not sure I ever checked it for portal compatibilith. Can ypi confirm what skin you are using and I'll try to generate a Jira ticket to get this fixed? Scott On Friday, June 11, 2010, Yves Deschamps wrote: Oups, the attached file is lost... I have that: 10 juin 2010 18:15:39 org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl getSkin ATTENTION: Impossible de trouver une apparence correspondant à la famille minimalFamily et au kit renderkit portlet. Utilisation de l'apparence simple Thank's Yves Deschamps a écrit : Here is my tomcat screen (attached file). Michael Freedman a écrit : Can you provide more information? What specific warnings are you seeing? Anything else? On 6/10/2010 6:50 AM, Yves Deschamps wrote: Hi, My JSF Trinidad application (servlet) run. But in portlet mode the skins are not found (warning message)... An idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25 -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: portletbridge action don't work
Thank you Michael
I solve my problem like this, it's ok now.
target="#{commonController.indexTitle}" />
Michael Freedman a écrit :
Any chance you can send us the (source) code for this sample so I can
look through it and try to see what might be wrong?
Also can you clarify what your problem is? Are you saying that it
only runs as a servlet and not as a portlet? I.e. you can register
the portlet but it never renders? Or are you saying that it runs as a
portlet and generally works though after refreshing a page the actions
on the page don't work? It sounds liek the later but your statements
at the beginning of the message are confusing
Also, what version of the bridge are you using? alpha2? Any chance
you can build a version from the main trunk?
(http://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/trunk) as
we are just about to release this version as 1.0.0 and hence has many
bug improvements since alpha2.
Finally, when the action isn't navigating are you seeing any
additional information being output to the log? Maybe you can send
the log along as well?
-Mike-
On 6/8/2010 7:50 AM, Yves Deschamps wrote:
Hi all,
I am using
Myfaces trinidad JSF 1.2
Myfaces PortletBridge (1.0)
uPortal 3.2 container
My JSF application (servlet) run but not in portlet mode.
When i see the home page after some refreshs, this action don't work...
actionListener="#{commonController.titleActionListener}" action="page">
titleActionListener is ok, i see the title in log...
public String titleActionListener(ActionEvent action) {
CoreCommandLink link = (CoreCommandLink) action.getComponent();
HtmlOutputText html = (HtmlOutputText) link.getChildren().get(0);
title = (String) html.getValue();
logger.info("Title: " + title);
return null;
}
page
/page.jsp
But nothing change in portlet...
An idea ?
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Re: Portletbride and Trinidad skin not found
Oups, the attached file is lost... I have that: 10 juin 2010 18:15:39 org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl getSkin ATTENTION: Impossible de trouver une apparence correspondant à la famille minimalFamily et au kit renderkit portlet. Utilisation de l'apparence simple Thank's Yves Deschamps a écrit : Here is my tomcat screen (attached file). Michael Freedman a écrit : Can you provide more information? What specific warnings are you seeing? Anything else? On 6/10/2010 6:50 AM, Yves Deschamps wrote: Hi, My JSF Trinidad application (servlet) run. But in portlet mode the skins are not found (warning message)... An idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: Portletbride and Trinidad skin not found
Here is my tomcat screen (attached file). Michael Freedman a écrit : Can you provide more information? What specific warnings are you seeing? Anything else? On 6/10/2010 6:50 AM, Yves Deschamps wrote: Hi, My JSF Trinidad application (servlet) run. But in portlet mode the skins are not found (warning message)... An idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Portletbride and Trinidad skin not found
Hi, My JSF Trinidad application (servlet) run. But in portlet mode the skins are not found (warning message)... An idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: portletbridge action don't work
Thank you Scott
I solve my problem like this, it's ok now.
target="#{commonController.indexTitle}" />
Scott O'Bryan a écrit :
I have no clue on the Yves.. Does it work without the actionListener?
On 06/08/2010 08:50 AM, Yves Deschamps wrote:
Hi all,
I am using
Myfaces trinidad JSF 1.2
Myfaces PortletBridge (1.0)
uPortal 3.2 container
My JSF application (servlet) run but not in portlet mode.
When i see the home page after some refreshs, this action don't work...
actionListener="#{commonController.titleActionListener}" action="page">
titleActionListener is ok, i see the title in log...
public String titleActionListener(ActionEvent action) {
CoreCommandLink link = (CoreCommandLink) action.getComponent();
HtmlOutputText html = (HtmlOutputText) link.getChildren().get(0);
title = (String) html.getValue();
logger.info("Title: " + title);
return null;
}
page
/page.jsp
But nothing change in portlet...
An idea ?
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
portletbridge action don't work
Hi all,
I am using
Myfaces trinidad JSF 1.2
Myfaces PortletBridge (1.0)
uPortal 3.2 container
My JSF application (servlet) run but not in portlet mode.
When i see the home page after some refreshs, this action don't work...
actionListener="#{commonController.titleActionListener}" action="page">
titleActionListener is ok, i see the title in log...
public String titleActionListener(ActionEvent action) {
CoreCommandLink link = (CoreCommandLink) action.getComponent();
HtmlOutputText html = (HtmlOutputText) link.getChildren().get(0);
title = (String) html.getValue();
logger.info("Title: " + title);
return null;
}
page
/page.jsp
But nothing change in portlet...
An idea ?
--
Yves Deschamps
Université de Lille 1
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
session and don't find skin in portlet mode
Hi, I try to run a JSF 1.2 Trinidad application (servlet) with uPortal in portlet mode. I use portlet-bridge and i have 2 errors: "Page needs a session and not is available..." And after refresh... "Impossible de trouver une apparence correspondant à la famille iphoneFamily et au kit render kit portlet" An Idea ? -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Re: Error with deploying portlet in uportal with portlet bridge
Hi Michael, It's OK now, thank you ! Michael Freedman a écrit : You seem to have the Faces servlet defined twice: as "Faces Servlet" and "faces" while only having the "Faces Servlet" mapped to a path (*.jsf) -- see bold sections below. Alas, the bridge uses a simple parser which only expects to find one servlet defintion for Faces. Since "faces" is the last one it encounters and there is no mapping for it I suspect this is the reason you are getting the error. Try/Fix this by removing the duplicate entry and let me know. If there is some reason you need to keep both please let me know and I can look at fixing this in the bridge.* faces javax.faces.webapp.FacesServlet * On 5/26/2010 6:38 AM, Yves Deschamps wrote: I have this error: Caused by: javax.portlet.faces.BridgeException: BridgeImpl.init(): unable to determine Faces servlet web.xml mapping. at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.init(BridgeImpl.java:204) at javax.portlet.faces.GenericFacesPortlet.initBridge(GenericFacesPortlet.java:562) with this web.xml. Have you an idea ? 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";> esup-annuaire-mobile javax.servlet.jsp.jstl.fmt.localizationContext resources.application javax.faces.STATE_SAVING_METHOD client org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE false org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION true org.apache.myfaces.trinidad.CHANGE_PERSISTENCE session trinidad org.apache.myfaces.trinidad.webapp.TrinidadFilter trinidad faces org.springframework.web.context.ContextLoaderListener * Faces Servlet javax.faces.webapp.FacesServlet 1 faces javax.faces.webapp.FacesServlet * resources org.apache.myfaces.trinidad.webapp.ResourceServlet Faces Servlet *.jsf resources /adf/* 15 org.apache.myfaces.ERROR_HANDLING false 500 /errordisplay.jsp index.html index.htm index.jsp default.html default.htm default.jsp BASIC esup-annuaire-mobile org.apache.pluto.core.PortletServlet portlet-class org.apache.portals.bridges.portletfilter.FilterPortlet portlet-guid esup-annuaire-mobile.EsupAnnuaireMobilePortlet portlet-name EsupAnnuaireMobilePortlet 1 esup-annuaire-mobile /PlutoInvoker/EsupAnnuaireMobilePortlet -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
Error with deploying portlet in uportal with portlet bridge
I have this error: Caused by: javax.portlet.faces.BridgeException: BridgeImpl.init(): unable to determine Faces servlet web.xml mapping. at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.init(BridgeImpl.java:204) at javax.portlet.faces.GenericFacesPortlet.initBridge(GenericFacesPortlet.java:562) with this web.xml. Have you an idea ? 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";> esup-annuaire-mobile javax.servlet.jsp.jstl.fmt.localizationContext resources.application javax.faces.STATE_SAVING_METHOD client org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE false org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION true org.apache.myfaces.trinidad.CHANGE_PERSISTENCE session trinidad org.apache.myfaces.trinidad.webapp.TrinidadFilter trinidad faces org.springframework.web.context.ContextLoaderListener Faces Servlet javax.faces.webapp.FacesServlet 1 faces javax.faces.webapp.FacesServlet resources org.apache.myfaces.trinidad.webapp.ResourceServlet Faces Servlet *.jsf resources /adf/* 15 org.apache.myfaces.ERROR_HANDLING false 500 /errordisplay.jsp index.html index.htm index.jsp default.html default.htm default.jsp BASIC esup-annuaire-mobile org.apache.pluto.core.PortletServlet portlet-class org.apache.portals.bridges.portletfilter.FilterPortlet portlet-guid esup-annuaire-mobile.EsupAnnuaireMobilePortlet portlet-name EsupAnnuaireMobilePortlet 1 esup-annuaire-mobile /PlutoInvoker/EsupAnnuaireMobilePortlet -- Yves Deschamps CRI Pôle Web, Environnement Numérique de Travail Bâtiment M4 Tel : 03 20 43 41 89 Fax : 03 20 43 66 25
