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" <[email protected]> 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 > <[email protected]> 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 >>>> <[email protected]> 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(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 >>>>> >>>>> >>>> >>>> >>> >>>
