You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Dan Jemiolo (JIRA)" <ji...@apache.org> on 2006/10/02 17:56:19 UTC
[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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Closed: (MUSE-120) ResourceManager should provide version of
getResources( ) that filters by resource type (context path)
Posted by "Dan Jemiolo (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MUSE-120?page=all ]
Dan Jemiolo closed MUSE-120.
----------------------------
Resolution: Fixed
Fixed: http://svn.apache.org/viewvc?view=rev&revision=452211
> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org