[
https://issues.redhat.com/browse/WFLY-13730?page=com.atlassian.jira.plugi...
]
Darran Lofthouse commented on WFLY-13730:
-----------------------------------------
TBH [~brian.stansberry] I think with the changes I have coming in we can remove the
dependency on the JACC service from the application-security-domain service and instead
use the boolan as an indicator JACC is required - maybe log a warning if not available and
requested.
The long term plan is to get rid of these application-security-domain-resources entirely.
WFLY-9440 fix breaks Galleon provisioning
-----------------------------------------
Key: WFLY-13730
URL:
https://issues.redhat.com/browse/WFLY-13730
Project: WildFly
Issue Type: Bug
Components: Build System, EJB
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Major
The WFLY-9440 fix breaks server provisioning in my EE9 branch. This is because the
feature-spec Galleon generates for the resource doesn't comprehend that the value of
the 'enable-jacc' attribute is not relevant to the required capability so it
expects to find a 'org.wildfly.security.jacc-policy.false' capability.
I'm not sure why it doesn't break things elsewhere.
There are a few possible ways to deal with this:
1) Don't register BooleanCapabilityReferenceRecorder with the ENABLE_JACC
AttributeDefinition; instead manually do its work in the add/remove/write-attribute
handlers. This essentially hides the capability relationship from Galleon by removing it
from the resource description metadata and seems to work.
2) Have BooleanCapabilityReferenceRecorder correctly implement
getRequirementPatternSegments to return an empty array. Perhaps this alone would fix it,
but I doubt it.
3) Combine #2 with a change of some sort in WildFly Core's
ReadFeatureDescriptionHandler to better understand and deal with this particular pattern.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)