myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Kahovec <jakub.kaho...@googlemail.com>
Subject Re: PortletBridge starting portlet problem
Date Wed, 01 Sep 2010 09:29:33 GMT
The factories are actually set per the context classloader, not per thread,
so it is a synchronization issue.

Jakub

On 1 September 2010 00:49, Scott O'Bryan <darkarena@gmail.com> wrote:

> 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" <darkarena@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.freedman@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.deschamps@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;init&gt;(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
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message