[
https://issues.apache.org/jira/browse/MUSE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Jemiolo closed MUSE-252.
----------------------------
Resolution: Fixed
The bug in getResourceDefinition() was fixed back in 2.1.0. I went ahead and
added the fix for getResourceEPRs() as well.
> 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
> Fix For: 2.3.0
>
>
> 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]
