Dan, Won't be a problem for me.
Cheers, Joel -----Original Message----- From: Dan Jemiolo (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 11:56 AM To: [email protected] Subject: [jira] Created: (MUSE-120) ResourceManager should provide version of getResources( ) that filters by resource type (context path) ResourceManager should provide version of getResources( ) that filters by resource type (context path) ------------------------------------------------------------------------ ------------------------------ Key: MUSE-120 URL: http://issues.apache.org/jira/browse/MUSE-120 Project: Muse Issue Type: Improvement Components: Core Engine - Resource and Capability APIs Affects Versions: 2.0.0 Reporter: Dan Jemiolo Assigned To: Dan Jemiolo Priority: Minor Fix For: 2.1.0 We've had a request for a version of ResourceManager.getResources( ) that returns all instances of a given resource type. This would require the addition of one method to ResourceManager and the implementation of that method to SimpleResourceManager. This may affect OSGiResourceManager - Joel will need to confirm. The new interface would be backwards compatible with the 2.0 version, since it's just adding a method. The easiest implementation is also the safest, as it does not modify any existing code in SimpleResourceManager. It would use the current getResourceContextPath( ) method and then look through the EPR hash table to find EPRs that had the given context path. If we decide to do this implementation, it would easily fall into the realm of "minor improvement" and meet our 2.1 criteria. However - this implementation is also much slower than it could be (it's a linear search). We could alter the SimpleResourceManager implementation to store the EPR/resource mapping differently and improve the speed of the lookup without affecting the more general EPR/resource lookup. Of course, this requires changing SimpleResourceManager code and is more drastic than the first option. Given that the more general lookup is essential to basic Muse request handling and we do not know how widespread use of the new method will be, I say we go with the first option for 2.1 and document the performance consideration in the JavaDoc. -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
