You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Joe Bohn (JIRA)" <de...@geronimo.apache.org> on 2005/08/03 19:02:35 UTC
[jira] Created: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
---------------------------------------------------------------------------------------------------------------------
Key: GERONIMO-846
URL: http://issues.apache.org/jira/browse/GERONIMO-846
Project: Geronimo
Type: Bug
Components: management
Versions: 1.0-M4
Environment: Windows XP
Reporter: Joe Bohn
Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
I propose the following:
1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=comments#action_12329652 ]
Aaron Mulder commented on GERONIMO-846:
---------------------------------------
Patch seems fine, but this issue depends on a fix for the Jetty log GBean
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Assignee: Aaron Mulder
> Fix For: 1.0-M5
> Attachments: logSettings.diff, logSettings.patch
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ]
Aaron Mulder updated GERONIMO-846:
----------------------------------
Fix Version: 1.0-M5
Assign To: Aaron Mulder
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Assignee: Aaron Mulder
> Fix For: 1.0-M5
> Attachments: logSettings.diff, logSettings.patch
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Joe Bohn (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ]
Joe Bohn updated GERONIMO-846:
------------------------------
Attachment: logSettings.patch
Updated patch to account for Web Console moving from sandbox to main
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Attachments: logSettings.diff, logSettings.patch
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Joe Bohn (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ]
Joe Bohn updated GERONIMO-846:
------------------------------
Component: common
Also indicated that the "common" component was affected since this changes the Log4JService.
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Attachments: logSettings.diff
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Joe Bohn (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=comments#action_12329660 ]
Joe Bohn commented on GERONIMO-846:
-----------------------------------
The fix for the jetty gbean problem is in GERONIMO-1006. The GBean problem was introduced after this fix was created by changing the Jetty GBean name. However, if you apply 1006 prior to this jira then you should get better results.
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Assignee: Aaron Mulder
> Fix For: 1.0-M5
> Attachments: logSettings.diff, logSettings.patch
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ]
Aaron Mulder closed GERONIMO-846:
---------------------------------
Resolution: Fixed
Applied the provided patch in revision 289878
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Assignee: Aaron Mulder
> Fix For: 1.0-M5
> Attachments: logSettings.diff, logSettings.patch
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-846) Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
Posted by "Joe Bohn (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-846?page=all ]
Joe Bohn updated GERONIMO-846:
------------------------------
Attachment: logSettings.diff
I've updated both the LogManagerPortlet to only invoke methods to change items in the Logger if a change has in fact been made at the console.
I've also updated the Log4jService so that it will not attempt to make a change unless the value of the new attribute has in fact been changed.
I did this for the root level, root properties file, and root refresh interval. We could/should probably make similar changes for the other loggers.
The last update will now win (either from the GUI or via an edit on the properties file) and any changes made from the GUI will be active until the
next recycle of the server (or change in the file).
> Log Level set on Console is overridden by serverlog properties setting even if the properties setting hasn't changed.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-846
> URL: http://issues.apache.org/jira/browse/GERONIMO-846
> Project: Geronimo
> Type: Bug
> Components: management, common
> Versions: 1.0-M4
> Environment: Windows XP
> Reporter: Joe Bohn
> Attachments: logSettings.diff
>
> Each update action from the LogManagerPortlet invokes the appropriate 3 methods on the SystemLog without checking for actual changes in the submitted values. For the refresh interval this isn't a problem because Log4JService checks itself to ensure the period has changed before updating the value. For the logging level this also isn't a problem because there is no ill effect to updating the level with the exact same level. However, when setting the ConfigFileName the Log4JService doesn't check the value and assumes that there really is a new file and therefore sets the lastChanged value to -1 to ensure that the file values will take effect on the next timer refresh. The result is that any change (including only a change to the logging level) from the console also guarantees that the file settings will be refreshed.
> I propose the following:
> 1) Change the LogManagerPortlet to ensure that the name or level has changed before updating the SystemLog (Log4JService) ... I'd also ensure that we check for changes in the refresh period as well just for good measure. This way we won't was time setting things that haven't changed.
> 2) Change the Log4JService to always check for an actual change to the level and/or the configPathName before taking any real action (just as it does for refresh interval today). This will clean things up so that another object invoking this service unnecessarily doesn't create a similar problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira