[jboss-jira] [JBoss JIRA] (WFCORE-692) read-resource-children(include-aliases=true) can return phantom results if another resource exists with the same key

Paul Ferraro (JIRA) issues at jboss.org
Wed May 13 20:34:20 EDT 2015


     [ https://issues.jboss.org/browse/WFCORE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFCORE-692:
--------------------------------
    Description: 
If a resource exists with the same key as the target address of a resource alias, read-resource-children
Just because an alias is registered doesn't mean a child resource necessarily exists at the target address.  The handler needs to validate that a resource actually exists at the target address rather than assuming it does.  This causes read-resource(recursive=true, include-aliases=true) to fail.

Here's an example:
I have a alias registered that translates:
{noformat}/subsystem=infinispan/cache-container=*/local-cache=*/file-store=FILE_STORE{noformat}
to:
{noformat}/subsystem=infinispan/cache-container=*/local-cache=*/store=file{noformat}

If I create a cache without a file cache store (which is perfectly valid), the corresponding read-resource operation returns a child for file-store=FILE_STORE, even though it returns no child for file=store (the target address), since no such child resource exists.

This is very problematic, since it makes aliases impossible to use if the target child resource is not always present.


  was:
Just because an alias is registered doesn't mean a child resource necessarily exists at the target address.  The handler needs to validate that a resource actually exists at the target address rather than assuming it does.  This causes read-resource(recursive=true, include-aliases=true) to fail.

Here's an example:
I have a alias registered that translates:
{noformat}/subsystem=infinispan/cache-container=*/local-cache=*/file-store=FILE_STORE{noformat}
to:
{noformat}/subsystem=infinispan/cache-container=*/local-cache=*/store=file{noformat}

If I create a cache without a file cache store (which is perfectly valid), the corresponding read-resource operation returns a child for file-store=FILE_STORE, even though it returns no child for file=store (the target address), since no such child resource exists.

This is very problematic, since it makes aliases impossible to use if the target child resource is not always present.



> read-resource-children(include-aliases=true) can return phantom results if another resource exists with the same key
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-692
>                 URL: https://issues.jboss.org/browse/WFCORE-692
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.0.CR3
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> If a resource exists with the same key as the target address of a resource alias, read-resource-children
> Just because an alias is registered doesn't mean a child resource necessarily exists at the target address.  The handler needs to validate that a resource actually exists at the target address rather than assuming it does.  This causes read-resource(recursive=true, include-aliases=true) to fail.
> Here's an example:
> I have a alias registered that translates:
> {noformat}/subsystem=infinispan/cache-container=*/local-cache=*/file-store=FILE_STORE{noformat}
> to:
> {noformat}/subsystem=infinispan/cache-container=*/local-cache=*/store=file{noformat}
> If I create a cache without a file cache store (which is perfectly valid), the corresponding read-resource operation returns a child for file-store=FILE_STORE, even though it returns no child for file=store (the target address), since no such child resource exists.
> This is very problematic, since it makes aliases impossible to use if the target child resource is not always present.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


More information about the jboss-jira mailing list