I doubt it's a synchronization issue since the Factory is complaining that it already exists for a particular thread.
That to me seems to imply it's single threaded. Sent from my iPhone On Aug 31, 2010, at 3:52 PM, Michael Freedman <michael.freed...@oracle.com> wrote: > Did you see the latest e-mail/comment on the thread with the subject line: > "Re: [Trinidad] java.lang.IllegalStateException: Factory already available > for this class loader"? Sounds plausible that the lack of synchronization is > causing this problem. You can either wait to hear from the Trinidad guys/and > hopefully get a patch/fix or try patching the Trinidad code yourself and > rebuilding. Let me know me know what you think. By the way it seems a > little strange the portal is sending two (simulanteous) requests. Yes > portlet 2.0 can have a 2 request render (one to get the headers) and one to > get the body -- so maybe its that. But you are using portlet 1.0 > (bridge)/portlet 1.0 container. I wonder if uPortal has a bug where the > portal itself knows about portlet 2.0 but isn't smart enough to detect the > container is 1.0 so sends the double render request (one to get the headers > and the other to get the body) as they only differ from a request perspective > by a flag in the request? Anyway if this is the problem and you were running > in a portlet 2.0 container you could check for this flag in a subclass of the > GenericFacesPortlet and when set to Header merely return without delegating > to the bridge. But since you are running in a 1.0 container I have no clue. > -Mike- > > On 8/30/2010 8:39 AM, Yves Deschamps wrote: >> It means "Factory already available for this class loader" >> >> Thanks... >> >> Scott O'Bryan a �crit : >>> Yay.. Exception translation at work. Yves, can you tell us what that >>> message states in English? Sorry, half the characters didn't come >>> through. >>> >>> Sent from my iPhone >>> >>> On Aug 30, 2010, at 6:50 AM, Yves Deschamps >>> <yves.descha...@univ-lille1.fr> wrote: >>> >>> >>>> Hi Michael, >>>> >>>> I just come back from holidays. >>>> >>>> I try my app with this environment: >>>> >>>> trinidad 1.2.15-SNAPSHOT (30/08/2010) >>>> portlet-bridge 1.0.0 (distribution) >>>> myfaces 1.2.9 (distribution) >>>> >>>> portlet-api-1.0 >>>> pluto... 1.1.7 >>>> >>>> uPortal-3.2.1 >>>> >>>> The result is : >>>> >>>> Caused by: java.lang.IllegalStateException: Factory d�j� disponible >>>> pour ce chargeur de classe. >>>> at >>>> org.apache.myfaces.trinidad.context.RequestContextFactory.setFactory(RequestContextFactory.java:54) >>>> at >>>> org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(GlobalConfiguratorImpl.java:391) >>>> at >>>> org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) >>>> at >>>> org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:334) >>>> at >>>> org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.<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 >>>> >>>> >>> >>> >> >>
