[opencms-dev] Applet upload bug on WebSphere 6.0 [VICTORY!!]

Chirouze Olivier olivier.chirouze at volvo.com
Wed Jun 25 12:36:15 CEST 2008


Hi list, hi Michael.

I didn't give up but it took some time to...
** Fix the bug!! **

I have created a bug on OpenCms Bugzilla: http://bugzilla.opencms.org/show_bug.cgi?id=1626.
I would like to mark the bug as "fixed" but could you tell me what is the way to commit (or suggest) my changes so that the fix is included in next release?

Reminder: the bug is on Applet upload not working on WebSphere Application Server.

Following is the complete bugfix explanation (sorry for technical details!):

- in fact, on Tomcat or WebSphere, the way the HTTP Session is recovered when the Applet is closed (the user chose a file to upload) is different. This all happens in org.opencms.main.CmsSessionManager.java.
- For some reason, Tomcat gets the session directly from HTTP request (it's actually a RequestFacade)
- it seems that OpenCms tryes to handle the case where the session was lost when lauching the Applet. And this is what happens on WebSphere. The HTTPRequest object lost its session. The idea is to look for that session in a hashmap of sessions, the key beeing a "session Id".
- that's where the problem is: the session Id that was passed by the Applet was just not the right key to look for. The value used was JSESSIONID (stored as a cookie), which is not a correct UUID, nor a key to look for a session.
- The correct value is a special OpenCms attribute, CmsSessionInfo.ATTRIBUTE_SESSION_ID... NOT the JSESSIONID.

So... The bugfix is... (drum rolls please):

In org.opencms.workplace.explorer.CmsNewResourceUpload.java, line 558 must be changed
FROM	: String sessionId = session.getId();
TO	: String sessionId = ((CmsUUID)session.getAttribute(CmsSessionInfo.ATTRIBUTE_SESSION_ID)).getStringValue();

Now, the applet gets the correct key, passes it to the servlet when going back to "proper" Java code, and the session is found. Everything works, on Tomcat and WebSphere Application Server :-))

I think the bug never appeared because that piece of code was not used by Tomcat.

Olivier

> -----Original Message-----
> From: opencms-dev-bounces at opencms.org 
> [mailto:opencms-dev-bounces at opencms.org] On Behalf Of Michael Moossen
> Sent: 13 June 2008 17:09
> To: The OpenCms mailing list
> Subject: Re: [opencms-dev] Applet upload bug on WebSphere 6.0
> 
> Hi Olivier!
> 
> Good to see that you have not give up ;)
> 
> You have to debug the FileUploadApplet class, which sets that cookie.
> you find this class under src-components.
> 
> HTH
> 
> Kind regards,
> Michael
> 
> -------------------
> 
> Alkacon Software GmbH  - The OpenCms Experts
> http://www.alkacon.com - http://www.opencms.org
> 
> 
> Chirouze Olivier wrote:
> > Hi list.
> > 
> > I finally managed to install, run, and debug OpenCms 7.0.4 
> on WebSphere 
> > 6.0.
> > It seems the "applet upload bug" is not related to Oracle but to 
> > WebSphere. I reproduced the bug locally, connected to mysql.
> > 
> > Here's the technical part:
> > 
> > It seems to be linked with JSESSION ID, as the exception is 
> thrown when 
> > calling getSessionInfo(). The value throws an exception 
> when trying to 
> > get Sessino information. The value used in OpenCms code 
> (constructor of 
> > class CmsUUID, parameter uuid) was : 
> lpILkdTn8JRnlRPijS-7-Sk. That value 
> > threw a NumberFormatException (it is not, indeed, a 36-char value)
> > 
> > Here's a screenshot of my firefox cookie:
> > 
> > Picture (Device Independent Bitmap)
> > 
> > The exception was thrown the first time I a CmsUUID was 
> built, after I 
> > clicked on "choose" (in the applet). The whole debug track is:
> > 
> > CmsUUID.<init>(String) line: 130       
> > CmsSessionManager.getSessionUUID(String) line: 467     
> > CmsSessionManager.getSessionInfo(String) line: 226     
> > CmsSessionManager.getSessionInfo(HttpServletRequest) line: 191 
> > OpenCmsCore.initCmsObjectFromSession(HttpServletRequest) 
> line: 869     
> > OpenCmsCore.initCmsObject(HttpServletRequest, 
> HttpServletResponse) line: 
> > 2066  
> > OpenCmsCore.showResource(HttpServletRequest, 
> HttpServletResponse) line: 
> > 1489   
> > OpenCmsServlet.doGet(HttpServletRequest, 
> HttpServletResponse) line: 152
> > OpenCmsServlet.doPost(HttpServletRequest, 
> HttpServletResponse) line: 
> > 164       
> > OpenCmsServlet(HttpServlet).service(HttpServletRequest, 
> > HttpServletResponse) line: 763 
> > OpenCmsServlet(HttpServlet).service(ServletRequest, 
> ServletResponse) 
> > line: 856 
> > ServletWrapper.service(ServletRequest, ServletResponse, 
> > WebAppServletInvocationEvent) line: 1694       
> > ServletWrapper.handleRequest(ServletRequest, 
> ServletResponse) line: 823
> > CacheServletWrapper.handleRequest(ServletRequest, 
> ServletResponse) line: 
> > 90    
> > WebContainer.handleRequest(IRequest, IResponse) line: 1936     
> > WCChannelLink.ready(VirtualConnection) line: 116       
> > HttpInboundLink.handleDiscrimination() line: 434       
> > HttpInboundLink.handleNewInformation() line: 373       
> > HttpInboundLink.ready(VirtualConnection) line: 253     
> > 
> NewConnectionInitialReadCallback.sendToDiscriminaters(VirtualC
> onnection, 
> > TCPReadRequestContext, boolean) line: 207     
> > 
> > NewConnectionInitialReadCallback.complete(VirtualConnection, 
> > TCPReadRequestContext) line: 109  
> > WorkQueueManager.requestComplete(TCPBaseRequestContext, 
> IOException) 
> > line: 566 
> > WorkQueueManager.attemptIO(TCPBaseRequestContext, boolean) 
> line: 619   
> > WorkQueueManager.workerRun(TCPBaseRequestContext, 
> IOException) line: 
> > 952       
> > WorkQueueManager$Worker.run() line: 1039       
> > ThreadPool$Worker.run() line: 1475     
> > 
> > The method where the exception is catched is:
> > 
> > 
> > *protected** void* showResource(HttpServletRequest req, 
> > HttpServletResponse res) {
> > 
> >         CmsObject cms =* null*;
> >        * try* {
> >             cms = initCmsObject(req, res);
> >             // user is initialized, now deliver the 
> requested resource
> >             CmsResource resource = initResource(cms, 
> > cms.getRequestContext().getUri(), req, res);
> >            * if* (resource !=* null*) {
> >                 // a file was read, go on process it
> >                 m_resourceManager.loadResource(cms, 
> resource, req, res);
> >                 m_sessionManager.updateSessionInfo(cms, req);
> >             }
> > 
> >         }* catch* (Throwable t) {
> >             errorHandling(cms, req, res, t);
> >         }
> >     }
> > 
> > The exception and backtrace are:
> > 
> > java.lang.NumberFormatException: UUID has to be represented by the 
> > standard 36-char representation
> > 
> > class org.safehaus.uuid.UUID
> > class org.opencms.util.CmsUUID
> > class org.opencms.main.CmsSessionManager
> > class org.opencms.main.CmsSessionManager
> > class org.opencms.main.CmsSessionManager
> > class org.opencms.main.OpenCmsCore
> > class org.opencms.main.OpenCmsCore
> > class org.opencms.main.OpenCmsCore
> > class org.opencms.main.OpenCmsServlet
> > class org.opencms.main.OpenCmsServlet
> > class javax.servlet.http.HttpServlet
> > class javax.servlet.http.HttpServlet
> > class com.ibm.ws.webcontainer.servlet.ServletWrapper
> > class com.ibm.ws.webcontainer.servlet.ServletWrapper
> > class com.ibm.ws.webcontainer.servlet.CacheServletWrapper
> > class com.ibm.ws.webcontainer.WebContainer
> > class com.ibm.ws.webcontainer.channel.WCChannelLink
> > class com.ibm.ws.http.channel.inbound.impl.HttpInboundLink
> > class com.ibm.ws.http.channel.inbound.impl.HttpInboundLink
> > class com.ibm.ws.http.channel.inbound.impl.HttpInboundLink
> > class com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback
> > class com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback
> > class com.ibm.ws.tcp.channel.impl.WorkQueueManager
> > class com.ibm.ws.tcp.channel.impl.WorkQueueManager
> > class com.ibm.ws.tcp.channel.impl.WorkQueueManager
> > class com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker
> > class com.ibm.ws.util.ThreadPool$Worker
> > 
> > I don't know why this happens here and not elsewhere. Other 
> values for 
> > uuid I saw where URLs, and other strange values like 
> > c7a2e451-11b7-11db-91cd-fdbae480bac9 or 
> > c7a79f4c-11b7-11db-91cd-fdbae480bac9 or even 
> > 00000000-0000-0000-0000-000000000000: they passed without 
> error (but all 
> > had the same pattern). Only that specific JSESSIONID value 
> made it crash.
> > 
> > So... will that help someone fix it?
> > 
> > I'm available for some more tests: everything is now setup on my PC.
> > 
> > Thanks
> > 
> > Olivier
> > 
> > *Olivier CHIROUZE
> > */I&0 Infrastructure
> > / 
> > ___*Volvo Information 
> > Technology                                                  
>                                           *_** 
> > 
> > 
> > 402 avenue Charles de Gaulle    ( phone: +33 (0)4.72.96.89.39      
> > API: VNX 0A0 0 02                       6 telecopy: 
> +33(0)4.72.96.76.80
> > 69635 VĂ©nissieux Cedex - France * _olivier.chirouze at volvo.com_ 
> > <mailto:olivier.chirouze at external.renault-trucks.com>
> > 
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > 
> > _______________________________________________
> > This mail is sent to you from the opencms-dev mailing list
> > To change your list options, or to unsubscribe from the 
> list, please visit
> > http://lists.opencms.org/mailman/listinfo/opencms-dev
> 
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, 
> please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
> 



More information about the opencms-dev mailing list