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