[jira] Commented: (SCXML-114) Support for JEXL2
[ https://issues.apache.org/jira/browse/SCXML-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801420#action_12801420 ] Henri Biestro commented on SCXML-114: - I just wanted to be sure jexl2 could be easily integrated in SCXML and this will of course wait till jexl2 is released (hopefully soon now :-)). I let you decide wether a jexl2 and jexl1 integration should both live in the codeline; if both are needed, I can reissue a patch accordingly. Support for JEXL2 - Key: SCXML-114 URL: https://issues.apache.org/jira/browse/SCXML-114 Project: Commons SCXML Issue Type: Improvement Reporter: Henri Biestro Fix For: 1.0 Attachments: SCXML-114.patch JEXL 2.0 release being (hopefully) soon, it may make sense to use it instead of JEXL 1.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-320) .PerUserPoolDataSource.poolKeys can grow without limit
[ https://issues.apache.org/jira/browse/DBCP-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801492#action_12801492 ] Phil Steitz commented on DBCP-320: -- I agree - looks to me as though poolKeys can safely be eliminated. It appears to be a global cache for UserKey objects, reused across PerUserPoolDataSource instances and to have no purpose other than caching the UserKeys. It is private and used only in getPoolKey. .PerUserPoolDataSource.poolKeys can grow without limit -- Key: DBCP-320 URL: https://issues.apache.org/jira/browse/DBCP-320 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebb The private static variable .PerUserPoolDataSource.poolKeys (a HashMap) only ever has items added to it; the contents are never cleared. Every different datasource generates a new HashMap entry; every username+password generates a new entry in that map. This might perhaps become a problem for long-running applications with lots of different users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DBCP-320) .PerUserPoolDataSource.poolKeys can grow without limit
[ https://issues.apache.org/jira/browse/DBCP-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801492#action_12801492 ] Phil Steitz edited comment on DBCP-320 at 1/17/10 8:28 PM: --- I agree - looks to me as though poolKeys can safely be eliminated. It appears to be a global cache for UserKey objects, reused across PerUserPoolDataSource instances and to have no purpose other than caching the PoolKeys. It is private and used only in getPoolKey. was (Author: psteitz): I agree - looks to me as though poolKeys can safely be eliminated. It appears to be a global cache for UserKey objects, reused across PerUserPoolDataSource instances and to have no purpose other than caching the UserKeys. It is private and used only in getPoolKey. .PerUserPoolDataSource.poolKeys can grow without limit -- Key: DBCP-320 URL: https://issues.apache.org/jira/browse/DBCP-320 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebb The private static variable .PerUserPoolDataSource.poolKeys (a HashMap) only ever has items added to it; the contents are never cleared. Every different datasource generates a new HashMap entry; every username+password generates a new entry in that map. This might perhaps become a problem for long-running applications with lots of different users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-320) .PerUserPoolDataSource.poolKeys can grow without limit
[ https://issues.apache.org/jira/browse/DBCP-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved DBCP-320. -- Resolution: Fixed Fix Version/s: 1.4 Fixed in r900226 .PerUserPoolDataSource.poolKeys can grow without limit -- Key: DBCP-320 URL: https://issues.apache.org/jira/browse/DBCP-320 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebb Fix For: 1.4 The private static variable .PerUserPoolDataSource.poolKeys (a HashMap) only ever has items added to it; the contents are never cleared. Every different datasource generates a new HashMap entry; every username+password generates a new entry in that map. This might perhaps become a problem for long-running applications with lots of different users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DBCP-8) [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz reopened DBCP-8: I am concerned that the implemented solution creates a security problem, or at least a misleading security contract. If the use case we are trying to satisfy is database passwords being changed, it seems to me that we really do need to implement a close() method as Dirk suggested. Under the current implementation, getConnection(username, password) will continue to work with the old password, returning pooled connections created using the old password if these still exist in the pool. [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource -- Key: DBCP-8 URL: https://issues.apache.org/jira/browse/DBCP-8 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Michael T. Dean Assignee: Mark Thomas Fix For: 1.3 Attachments: dbcp-SharedPoolWithPasswordChange-20070309.patch, dbcp-SharedPoolWithPasswordChange.patch Problem Summary: Currently, DBCP does not provide support for dealing with password changes when using InstanceKeyDataSources. This means that when using a concrete implementation of InstanceKeyDataSource, such as SharedPoolDataSource or PerUserPoolDataSource, if a user changes his/her password, the entire connection pool must be restarted for DBCP to recognize the new password. In the event the connection pool is being managed by a container, such as Tomcat, it requires restarting the container. Users have previously requested an ability to handle these situations (see http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40b5f9dc.1080...@pandora.be%3e and http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40aca3de.8080...@pandora.be%3e for examples). Proposed Patch: The attached patch provides support for using the SharedPoolDataSource in situations where user passwords may be changed. Support is provided by changing UserPassKey and SharedPoolDataSource to use the concatenation of the username and password as the key. In this way, after a user changes password, a getConnection(String, String) method call will cause the pool to create a new Connection using the new username and password. The Connection that was created using the old username and password remains in the pool, where--assuming the pool is set up to remove idle objects--it will be collected by the idle object eviction thread or eventually (once the pool is full) be discarded according to the LRU algorithm provided by the pool. Other Solutions Considered: In making this patch, I considered several other possible algorithms but chose the implemented algorithm as the best combination of safety and ease of use. And--as a bonus--it is a very unobtrusive solution. :) - The public void close(String name) method recommended by Dirk Verbeeck in the first link above is relatively complex to implement in the case of a SharedPoolDataSource (but would be much easier for a PerUserPoolDataSource, as he suggested). In the case of a SharedPoolDataSource, it's possible that multiple Connections exist for the specified user, in which case SharedPoolDataSource would have to provide logic to deal with the cases where one or more existing connections for the user are checked out at the time the method is called--not to mention the logic required to find all existing connections and close them without needlessly opening new connections (since all users share the same pool in a SharedPoolDataSource instead of having a pool per user as in PerUserPoolDataSource). - Adding a method public void getConnection(String username, String password, boolean closeAndReconnectOnPasswordMismatch) has similar problems with the possibility of the existence of multiple open connections for the given username. If only the current connection is closed, we may be leaving connections that are associated with the old password in the pool; therefore, the application would need to use the closeAndReconnect functionality in most--if not all--cases where a connection is required. If all connections are closed, we have the same situation described above. Furthermore, neither of the above methods is a part of the DataSource interface; and, therefore, both would require the application to downcast to the appropriate DBCP type to make the method call. For all practical purposes, this negates the benefits of using an interface in the first place. Additionally, adding new methods as above requires the application to know when the user has changed his/her password, and provides a potential failure mode when the user changes
[jira] Commented: (DBCP-8) [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801647#action_12801647 ] Sebb commented on DBCP-8: - Seems to me that the only way that the code can know that the password has been changed is when an application calls getConnection() using the new password. So if the login succeeds, then this becomes the new password for the user, and any connections in the pool which have a different password for that user can be dropped, and any connections that are returned to the pool subsequently can be dropped if they don't match the new password. I've not looked at the code in detail - and it seems a bit too simple - so I may have overlooked something here. [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource -- Key: DBCP-8 URL: https://issues.apache.org/jira/browse/DBCP-8 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Michael T. Dean Assignee: Mark Thomas Fix For: 1.3 Attachments: dbcp-SharedPoolWithPasswordChange-20070309.patch, dbcp-SharedPoolWithPasswordChange.patch Problem Summary: Currently, DBCP does not provide support for dealing with password changes when using InstanceKeyDataSources. This means that when using a concrete implementation of InstanceKeyDataSource, such as SharedPoolDataSource or PerUserPoolDataSource, if a user changes his/her password, the entire connection pool must be restarted for DBCP to recognize the new password. In the event the connection pool is being managed by a container, such as Tomcat, it requires restarting the container. Users have previously requested an ability to handle these situations (see http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40b5f9dc.1080...@pandora.be%3e and http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40aca3de.8080...@pandora.be%3e for examples). Proposed Patch: The attached patch provides support for using the SharedPoolDataSource in situations where user passwords may be changed. Support is provided by changing UserPassKey and SharedPoolDataSource to use the concatenation of the username and password as the key. In this way, after a user changes password, a getConnection(String, String) method call will cause the pool to create a new Connection using the new username and password. The Connection that was created using the old username and password remains in the pool, where--assuming the pool is set up to remove idle objects--it will be collected by the idle object eviction thread or eventually (once the pool is full) be discarded according to the LRU algorithm provided by the pool. Other Solutions Considered: In making this patch, I considered several other possible algorithms but chose the implemented algorithm as the best combination of safety and ease of use. And--as a bonus--it is a very unobtrusive solution. :) - The public void close(String name) method recommended by Dirk Verbeeck in the first link above is relatively complex to implement in the case of a SharedPoolDataSource (but would be much easier for a PerUserPoolDataSource, as he suggested). In the case of a SharedPoolDataSource, it's possible that multiple Connections exist for the specified user, in which case SharedPoolDataSource would have to provide logic to deal with the cases where one or more existing connections for the user are checked out at the time the method is called--not to mention the logic required to find all existing connections and close them without needlessly opening new connections (since all users share the same pool in a SharedPoolDataSource instead of having a pool per user as in PerUserPoolDataSource). - Adding a method public void getConnection(String username, String password, boolean closeAndReconnectOnPasswordMismatch) has similar problems with the possibility of the existence of multiple open connections for the given username. If only the current connection is closed, we may be leaving connections that are associated with the old password in the pool; therefore, the application would need to use the closeAndReconnect functionality in most--if not all--cases where a connection is required. If all connections are closed, we have the same situation described above. Furthermore, neither of the above methods is a part of the DataSource interface; and, therefore, both would require the application to downcast to the appropriate DBCP type to make the method call. For all practical purposes, this negates the benefits of using an interface in the first place. Additionally, adding new methods as above requires the application to know when
[jira] Commented: (DBCP-8) [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801655#action_12801655 ] Phil Steitz commented on DBCP-8: You are describing one reasonable scenario. The code does not do this or anything similar. So if we keep it as is, we at least need to document the behavior. [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource -- Key: DBCP-8 URL: https://issues.apache.org/jira/browse/DBCP-8 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Michael T. Dean Assignee: Mark Thomas Fix For: 1.3 Attachments: dbcp-SharedPoolWithPasswordChange-20070309.patch, dbcp-SharedPoolWithPasswordChange.patch Problem Summary: Currently, DBCP does not provide support for dealing with password changes when using InstanceKeyDataSources. This means that when using a concrete implementation of InstanceKeyDataSource, such as SharedPoolDataSource or PerUserPoolDataSource, if a user changes his/her password, the entire connection pool must be restarted for DBCP to recognize the new password. In the event the connection pool is being managed by a container, such as Tomcat, it requires restarting the container. Users have previously requested an ability to handle these situations (see http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40b5f9dc.1080...@pandora.be%3e and http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40aca3de.8080...@pandora.be%3e for examples). Proposed Patch: The attached patch provides support for using the SharedPoolDataSource in situations where user passwords may be changed. Support is provided by changing UserPassKey and SharedPoolDataSource to use the concatenation of the username and password as the key. In this way, after a user changes password, a getConnection(String, String) method call will cause the pool to create a new Connection using the new username and password. The Connection that was created using the old username and password remains in the pool, where--assuming the pool is set up to remove idle objects--it will be collected by the idle object eviction thread or eventually (once the pool is full) be discarded according to the LRU algorithm provided by the pool. Other Solutions Considered: In making this patch, I considered several other possible algorithms but chose the implemented algorithm as the best combination of safety and ease of use. And--as a bonus--it is a very unobtrusive solution. :) - The public void close(String name) method recommended by Dirk Verbeeck in the first link above is relatively complex to implement in the case of a SharedPoolDataSource (but would be much easier for a PerUserPoolDataSource, as he suggested). In the case of a SharedPoolDataSource, it's possible that multiple Connections exist for the specified user, in which case SharedPoolDataSource would have to provide logic to deal with the cases where one or more existing connections for the user are checked out at the time the method is called--not to mention the logic required to find all existing connections and close them without needlessly opening new connections (since all users share the same pool in a SharedPoolDataSource instead of having a pool per user as in PerUserPoolDataSource). - Adding a method public void getConnection(String username, String password, boolean closeAndReconnectOnPasswordMismatch) has similar problems with the possibility of the existence of multiple open connections for the given username. If only the current connection is closed, we may be leaving connections that are associated with the old password in the pool; therefore, the application would need to use the closeAndReconnect functionality in most--if not all--cases where a connection is required. If all connections are closed, we have the same situation described above. Furthermore, neither of the above methods is a part of the DataSource interface; and, therefore, both would require the application to downcast to the appropriate DBCP type to make the method call. For all practical purposes, this negates the benefits of using an interface in the first place. Additionally, adding new methods as above requires the application to know when the user has changed his/her password, and provides a potential failure mode when the user changes his/her password through an external application (i.e. directly on the database or using some other application). Although it is possible for the application to catch the plain-vanilla SQLException thrown by the getConnection(String, String) method of InstanceKeyDataSource and
[jira] Commented: (DBCP-8) [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801656#action_12801656 ] Phil Steitz commented on DBCP-8: To qualify my first statement above, after the patch the code is no less secure than before - i.e., before the patch, after a password change, the old password would continue to work as long as there were connections available in the pool (and they were not killed on the server side). After the patch, the changed password will work as well. [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource -- Key: DBCP-8 URL: https://issues.apache.org/jira/browse/DBCP-8 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Michael T. Dean Assignee: Mark Thomas Fix For: 1.3 Attachments: dbcp-SharedPoolWithPasswordChange-20070309.patch, dbcp-SharedPoolWithPasswordChange.patch Problem Summary: Currently, DBCP does not provide support for dealing with password changes when using InstanceKeyDataSources. This means that when using a concrete implementation of InstanceKeyDataSource, such as SharedPoolDataSource or PerUserPoolDataSource, if a user changes his/her password, the entire connection pool must be restarted for DBCP to recognize the new password. In the event the connection pool is being managed by a container, such as Tomcat, it requires restarting the container. Users have previously requested an ability to handle these situations (see http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40b5f9dc.1080...@pandora.be%3e and http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40aca3de.8080...@pandora.be%3e for examples). Proposed Patch: The attached patch provides support for using the SharedPoolDataSource in situations where user passwords may be changed. Support is provided by changing UserPassKey and SharedPoolDataSource to use the concatenation of the username and password as the key. In this way, after a user changes password, a getConnection(String, String) method call will cause the pool to create a new Connection using the new username and password. The Connection that was created using the old username and password remains in the pool, where--assuming the pool is set up to remove idle objects--it will be collected by the idle object eviction thread or eventually (once the pool is full) be discarded according to the LRU algorithm provided by the pool. Other Solutions Considered: In making this patch, I considered several other possible algorithms but chose the implemented algorithm as the best combination of safety and ease of use. And--as a bonus--it is a very unobtrusive solution. :) - The public void close(String name) method recommended by Dirk Verbeeck in the first link above is relatively complex to implement in the case of a SharedPoolDataSource (but would be much easier for a PerUserPoolDataSource, as he suggested). In the case of a SharedPoolDataSource, it's possible that multiple Connections exist for the specified user, in which case SharedPoolDataSource would have to provide logic to deal with the cases where one or more existing connections for the user are checked out at the time the method is called--not to mention the logic required to find all existing connections and close them without needlessly opening new connections (since all users share the same pool in a SharedPoolDataSource instead of having a pool per user as in PerUserPoolDataSource). - Adding a method public void getConnection(String username, String password, boolean closeAndReconnectOnPasswordMismatch) has similar problems with the possibility of the existence of multiple open connections for the given username. If only the current connection is closed, we may be leaving connections that are associated with the old password in the pool; therefore, the application would need to use the closeAndReconnect functionality in most--if not all--cases where a connection is required. If all connections are closed, we have the same situation described above. Furthermore, neither of the above methods is a part of the DataSource interface; and, therefore, both would require the application to downcast to the appropriate DBCP type to make the method call. For all practical purposes, this negates the benefits of using an interface in the first place. Additionally, adding new methods as above requires the application to know when the user has changed his/her password, and provides a potential failure mode when the user changes his/her password through an external application (i.e. directly on the database or using some other
[jira] Commented: (DBCP-8) [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12801665#action_12801665 ] Sebb commented on DBCP-8: - Sorry, I see my previous comment was ambiguous. What I meant was that the code could be AMENDED to keep track of the current user/password combination, and use that to invalidate connections which were set up using a different password. As far as I can tell, that would prevent the old password from being used again when getting a new connection from the pool. It would not stop an active connection from being used, but IMO that's really up to the database engine whether or not a password change has any effect on an open connection. Indeed, the database might insist all connections are closed before permitting a password change. With my suggestion, there's no need to change to the API, the user just needs to provide the new password, which is what they would do anyway. If the user provides a wrong new password, then the database connection will fail, and in that case obviously the current user/password mapping should not be changed. Won't that work? [dbcp][PATCH] Handle changed passwords in SharedPoolDataSource -- Key: DBCP-8 URL: https://issues.apache.org/jira/browse/DBCP-8 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Michael T. Dean Assignee: Mark Thomas Fix For: 1.3 Attachments: dbcp-SharedPoolWithPasswordChange-20070309.patch, dbcp-SharedPoolWithPasswordChange.patch Problem Summary: Currently, DBCP does not provide support for dealing with password changes when using InstanceKeyDataSources. This means that when using a concrete implementation of InstanceKeyDataSource, such as SharedPoolDataSource or PerUserPoolDataSource, if a user changes his/her password, the entire connection pool must be restarted for DBCP to recognize the new password. In the event the connection pool is being managed by a container, such as Tomcat, it requires restarting the container. Users have previously requested an ability to handle these situations (see http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40b5f9dc.1080...@pandora.be%3e and http://mail-archives.eu.apache.org/mod_mbox/jakarta-commons-user/200405.mbox/%3c40aca3de.8080...@pandora.be%3e for examples). Proposed Patch: The attached patch provides support for using the SharedPoolDataSource in situations where user passwords may be changed. Support is provided by changing UserPassKey and SharedPoolDataSource to use the concatenation of the username and password as the key. In this way, after a user changes password, a getConnection(String, String) method call will cause the pool to create a new Connection using the new username and password. The Connection that was created using the old username and password remains in the pool, where--assuming the pool is set up to remove idle objects--it will be collected by the idle object eviction thread or eventually (once the pool is full) be discarded according to the LRU algorithm provided by the pool. Other Solutions Considered: In making this patch, I considered several other possible algorithms but chose the implemented algorithm as the best combination of safety and ease of use. And--as a bonus--it is a very unobtrusive solution. :) - The public void close(String name) method recommended by Dirk Verbeeck in the first link above is relatively complex to implement in the case of a SharedPoolDataSource (but would be much easier for a PerUserPoolDataSource, as he suggested). In the case of a SharedPoolDataSource, it's possible that multiple Connections exist for the specified user, in which case SharedPoolDataSource would have to provide logic to deal with the cases where one or more existing connections for the user are checked out at the time the method is called--not to mention the logic required to find all existing connections and close them without needlessly opening new connections (since all users share the same pool in a SharedPoolDataSource instead of having a pool per user as in PerUserPoolDataSource). - Adding a method public void getConnection(String username, String password, boolean closeAndReconnectOnPasswordMismatch) has similar problems with the possibility of the existence of multiple open connections for the given username. If only the current connection is closed, we may be leaving connections that are associated with the old password in the pool; therefore, the application would need to use the closeAndReconnect functionality in most--if not all--cases where a connection is required. If all connections are closed, we have the same
