myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeanne Waldman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Created: (TRINIDAD-1987) For example, if I go to C:\Documents and Settings\jwaldman.ST-USERS\Application Data\JDeveloper\system11.1.2.0.38.58.67\o.j2ee\drs\Application1\ViewControllerWebApp.war\skins\skin2\images I see the 'old' images, until I stop/restart my server.
Date Thu, 23 Dec 2010 23:55:45 GMT
For example, if I go to C:\Documents and Settings\jwaldman.ST-USERS\Application Data\JDeveloper\system11.1.2.0.38.58.67\o.j2ee\drs\Application1\ViewControllerWebApp.war\skins\skin2\images
I see the 'old' images, until I stop/restart my server.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: TRINIDAD-1987
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1987
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Skinning
            Reporter: Jeanne Waldman
            Assignee: Jeanne Waldman


I was able to reproduce this consistently in Trinidad demos by
1. setting trinidad-config.xml to purple/default
2. running panelPageSkinDemo.jspx and pressing the "Skin Dirty" button.
3. I'd see a message about not being able to delete the file, then a message
about not being able to write to it. (FileSystemStyleCache> <_getWriter>
IOException while opening file for writing:)
Note: by consistently, sometimes it would happen every time I pressed the
Skin Dirty button, then later in the day I had to press it over and over for
about 5 minutes to see the error.

I investigated this for quite some time to rule out concurrency issues. I
looked at org.apache.myfaces.trinidad.webapp.ResourceServlet to make sure the
code in doGet wasn't reading the css file at the same time the code in
FileSystemStyleCache was trying to delete it or write to it. This was always
ok even when I saw the error.

When I got this error about not being able to delete the file, I went to the
css file on the filesystem, and tried deleting it by hand, and I got an error
saying that someone else is using the file.I downloaded a tool so I could see
what process was holding on to the file handle, and it was java.exe . I was running in JDeveloper.
After a minute or two, I would see the process would release the file.

To fix this issue, I plan to log an info message instead of throwing the exception.
 The css file will be there on the filesystem, and the browser will be able
to read it, so the application will not be affected.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message