You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "nadir amra (JIRA)" <ji...@apache.org> on 2008/04/16 18:47:22 UTC
[jira] Created: (AXIS2-3746) File setLastModified() in deployment
code causes problems
File setLastModified() in deployment code causes problems
---------------------------------------------------------
Key: AXIS2-3746
URL: https://issues.apache.org/jira/browse/AXIS2-3746
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: deployment
Reporter: nadir amra
Assignee: nadir amra
Priority: Critical
Fix For: nightly
I question the usage of the the File class's method setLastModified() in WSInfoList.java:
private void setLastModifiedDate(File file, WSInfo wsInfo) {
if (file.isDirectory()) {
File files [] = file.listFiles();
for (int i = 0; i < files.length; i++) {
File fileItem = files[i];
if (fileItem.isDirectory()) {
setLastModifiedDate(fileItem, wsInfo);
} else {
fileItem.setLastModified(wsInfo.getLastModifiedDate());
}
}
} else {
file.setLastModified(wsInfo.getLastModifiedDate());
}
}
I do not understand why we are actually modifying the last-modified-date of the file objects?
The main reason is that this causes problems when the user ID that AXIS2 is running under does not have authority to update the files. So the attempt to modify the files will not result on anything be done (we apparently do not check if operation failed), but more importantly, if system auditing is enabled you will see authority-failure auditing records for each attempt to modify the time-stamp for a file. And if hot-update is deployed, this will result in 1000's of these records.
Possible solution: Why do we need to test for equality when looking at time-stamps? We can save the newest last-modified time-stamp, and then when we want to detect if something has changed, we simply see if the saved time-stamp is greater or equal to the file time-stamp. And if this is true, then the file has not changed. Otherwise, the file has changed.....the added benefit is we do not have to update files.
I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2-3746) File setLastModified() in
deployment code causes problems
Posted by "nadir amra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590251#action_12590251 ]
nadiramra edited comment on AXIS2-3746 at 4/17/08 5:12 PM:
------------------------------------------------------------
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN 649334
was (Author: nadiramra):
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also.
> File setLastModified() in deployment code causes problems
> ---------------------------------------------------------
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
> Reporter: nadir amra
> Assignee: nadir amra
> Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is running under does not have authority to update the files. So the attempt to modify the files will not result on anything be done (we apparently do not check if operation failed), but more importantly, if system auditing is enabled you will see authority-failure auditing records for each attempt to modify the time-stamp for a file. And if hot-update is deployed, this will result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at time-stamps? We can save the newest last-modified time-stamp, and then when we want to detect if something has changed, we simply see if the saved time-stamp is greater or equal to the file time-stamp. And if this is true, then the file has not changed. Otherwise, the file has changed.....the added benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Closed: (AXIS2-3746) File setLastModified() in deployment
code causes problems
Posted by "nadir amra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nadir amra closed AXIS2-3746.
-----------------------------
Resolution: Fixed
Fix Version/s: 1.4
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also.
> File setLastModified() in deployment code causes problems
> ---------------------------------------------------------
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
> Reporter: nadir amra
> Assignee: nadir amra
> Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is running under does not have authority to update the files. So the attempt to modify the files will not result on anything be done (we apparently do not check if operation failed), but more importantly, if system auditing is enabled you will see authority-failure auditing records for each attempt to modify the time-stamp for a file. And if hot-update is deployed, this will result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at time-stamps? We can save the newest last-modified time-stamp, and then when we want to detect if something has changed, we simply see if the saved time-stamp is greater or equal to the file time-stamp. And if this is true, then the file has not changed. Otherwise, the file has changed.....the added benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2-3746) File setLastModified() in
deployment code causes problems
Posted by "nadir amra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590251#action_12590251 ]
nadiramra edited comment on AXIS2-3746 at 4/17/08 5:28 PM:
------------------------------------------------------------
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN 649334. The 1.4 branch fix is in SVN 649335.
was (Author: nadiramra):
Fixed. Much cleaner and correct now.
I will be putting this in the 1.4 release also. The trunk fix is in SVN 649334
> File setLastModified() in deployment code causes problems
> ---------------------------------------------------------
>
> Key: AXIS2-3746
> URL: https://issues.apache.org/jira/browse/AXIS2-3746
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: deployment
> Reporter: nadir amra
> Assignee: nadir amra
> Priority: Critical
> Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in WSInfoList.java:
> private void setLastModifiedDate(File file, WSInfo wsInfo) {
> if (file.isDirectory()) {
> File files [] = file.listFiles();
> for (int i = 0; i < files.length; i++) {
> File fileItem = files[i];
> if (fileItem.isDirectory()) {
> setLastModifiedDate(fileItem, wsInfo);
> } else {
> fileItem.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> } else {
> file.setLastModified(wsInfo.getLastModifiedDate());
> }
> }
> I do not understand why we are actually modifying the last-modified-date of the file objects?
> The main reason is that this causes problems when the user ID that AXIS2 is running under does not have authority to update the files. So the attempt to modify the files will not result on anything be done (we apparently do not check if operation failed), but more importantly, if system auditing is enabled you will see authority-failure auditing records for each attempt to modify the time-stamp for a file. And if hot-update is deployed, this will result in 1000's of these records.
> Possible solution: Why do we need to test for equality when looking at time-stamps? We can save the newest last-modified time-stamp, and then when we want to detect if something has changed, we simply see if the saved time-stamp is greater or equal to the file time-stamp. And if this is true, then the file has not changed. Otherwise, the file has changed.....the added benefit is we do not have to update files.
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org