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.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.<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)
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<String, Object> 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)
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)
Caused by:
org.jasig.portal.channels.portlet.PortletDispatchException: The
portlet window
'PortletWindowImpl[portletWindowId=118.n381,contextPath=/esup-news-mobile,portletName=EsupNewsMobilePortlet,windowState=maximized,portletMode=view,expirationCache=<null>,requestParameters={},delegationParent=<null>]'
threw an exception while executing render.
at
org.jasig.portal.portlet.rendering.PortletRendererImpl.doRender(PortletRendererImpl.java:236)
at
org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:376)
... 19 more
Caused by: javax.portlet.PortletException: doBridgeDispatch
failed: error from Bridge in executing the request
at
javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:509)
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)
Caused by: javax.portlet.faces.BridgeException:
java.lang.NullPointerException
at
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:643)
at
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545)
at
javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506)
... 38 more
Caused by: java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.getRenderKit(RenderKitDecorator.java:119)
at
org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.getResponseStateManager(RenderKitDecorator.java:70)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getResponseStateManager(RendererUtils.java:1184)
at
org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:141)
at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:80)
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)
... 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
