[
https://issues.apache.org/jira/browse/MUSE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515743
]
Bo Shao edited comment on MUSE-252 at 7/26/07 8:36 AM:
-------------------------------------------------------
I noticed the location of this bug as well when Balan forwarded this message to
me. Just change that method of getResourceEPRs into the following in
SimpleResourceManger.java:
public synchronized Iterator getResourceEPRs(String contextPath)
{
Set copy = new HashSet();
Iterator i = _resources.keySet().iterator();
//
// do a linear search through the collection of EPRs and keep those
// that have the given context path.
//
// NOTE: This could be improved if SimpleResourceManager were changed
// to keep one HashMap for each resource type (context path).
// This method would then become a O(1) operation just like the
// more generic getResource(EPR) method.
//
while (i.hasNext())
{
EndpointReference next = (EndpointReference)i.next();
String addressPath = next.getAddress().getRawPath();
// this is where the endsWith is used originally
// if (addressPath.endsWith(contextPath))
// copy.add(next);
int pos = addressPath.lastIndexOf("/");
if ((pos > 0) && (addressPath.substring(pos).equals(contextPath))) {
copy.add(next);
}
}
return copy.iterator();
}
was:
I noticed the location of this bug as well when Balan forward this message to
me. Just change that method of getResourceEPRs into the following in
SimpleResourceManger.java:
public synchronized Iterator getResourceEPRs(String contextPath)
{
Set copy = new HashSet();
Iterator i = _resources.keySet().iterator();
//
// do a linear search through the collection of EPRs and keep those
// that have the given context path.
//
// NOTE: This could be improved if SimpleResourceManager were changed
// to keep one HashMap for each resource type (context path).
// This method would then become a O(1) operation just like the
// more generic getResource(EPR) method.
//
while (i.hasNext())
{
EndpointReference next = (EndpointReference)i.next();
String addressPath = next.getAddress().getRawPath();
// this is where the endsWith is used originally
// if (addressPath.endsWith(contextPath))
// copy.add(next);
int pos = addressPath.lastIndexOf("/");
if ((pos > 0) && (addressPath.substring(pos).equals(contextPath))) {
copy.add(next);
}
}
return copy.iterator();
}
> Resource initialization and request dispatching issue when a resource type
> name is a substring of another resource type
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: MUSE-252
> URL: https://issues.apache.org/jira/browse/MUSE-252
> Project: Muse
> Issue Type: Bug
> Components: Core Engine - Routing and Serialization
> Affects Versions: 2.0.0
> Environment: Linux, java 1.5
> Reporter: Francesco Scandelli
> Assignee: Dan Jemiolo
> Priority: Minor
>
> If the name of a resource (let's call it "contained" resource) is a substring
> of another resource name ("containing" resource) and the "contained" resource
> is declared before the "containing" one within muse.xml, than any request to
> the "containing" resource is wrongly dispatched to the "contained" one.
> Test example:
> "contained" resource name: CSCFConfigurator
> "containing" resource name: ListaSCSCFConfigurator
> Vin Nguyen is aware of the bug, here is his comment:
> the bug is in SimpleResourceManager.getResourceDefinition(contextpath). It
> does a simple contextpath.endsWith() comparison. Instead, it should compare
> the entire token after the "/" in the contextpath. In your case,
> "ListaSCSCFConfigurator" ends in "SCSCFConfigurator", so the latter resource
> is returned because it was initialized first.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
