You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org> on 2010/12/24 00:55:45 UTC
[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.
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.
[jira] Resolved: (TRINIDAD-1987) IOException while opening file for
writing css file
Posted by "Jeanne Waldman (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeanne Waldman resolved TRINIDAD-1987.
--------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0.2-core
> IOException while opening file for writing css file
> ---------------------------------------------------
>
> 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
> Fix For: 2.0.0.2-core
>
>
> 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.