[
https://issues.jboss.org/browse/WFCORE-692?page=com.atlassian.jira.plugin...
]
Paul Ferraro updated WFCORE-692:
--------------------------------
Description:
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 unusable if the target child resource is
not always present.
read-resource(include-aliases=true) handler always returns aliased
children, even if no resource exists at the target address
-----------------------------------------------------------------------------------------------------------------------------
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
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)