[ 
https://issues.apache.org/jira/browse/MUSE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570020#action_12570020
 ] 

Kam K. Yee commented on MUSE-252:
---------------------------------

The fix checked in for getResourceEPRs() should be modified to 
"lastIndexOf("/") + 1"...

The forward slash should not be used in the equality comparison against the 
passed in context path string.

Doing so breaks consistency of the APIs. When doing Resource.getContextPath(), 
the string returned does not contain the forward slash. Having the user 
manually/explicitly add a forward slash just to perform getResourceEPRs() 
doesn't make much sense.

Please reopen and resubmit the fix.

Thanks!

> 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]

Reply via email to