[
https://issues.redhat.com/browse/WFLY-13674?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFLY-13674:
-----------------------------------------
The key value here IMHO is preventing deployments getting deployed that silently don't
function as expected, so I don't think providing parsing context is a requirement. If
expression resolution was enabled but the expression could not be resolved I don't
think we provide such information when it fails. Providing the unresolved text should be
sufficient to allow people to find the problem.
If it's reasonably straightforward to provide context, that's fine. Maybe the file
name context is possible, as the code the associates the replacer with the parser might
know. But I think providing the element/attribute name is likely too much as it would
involve changing all the parsers to provide that data. Those parsers come from a variety
of OSS projects, so getting consistent behavior would be a challenge.
I'm generally reluctant to add a lot of complexity and fragility to the server code in
order to improve error messages reporting on user mistakes, beyond what's readily
doable.
I think the scope of this would be the parsing that's governed by the two attributes
on the EE subsystem, both spec and jboss.
WARN if deployment descriptor has ${...} but
*property-replacement=false
------------------------------------------------------------------------
Key: WFLY-13674
URL:
https://issues.redhat.com/browse/WFLY-13674
Project: WildFly
Issue Type: Enhancement
Components: EE
Affects Versions: 20.0.0.Final
Reporter: Brad Maxwell
Assignee: Brian Stansberry
Priority: Major
WARN if deployment descriptor has ${...} but *property-replacement=false
By default the property replacement defaults to true for jboss deployment descriptors and
false for annotations and spec deployment descriptors:
{code:java}
"annotation-property-replacement" => false,
"jboss-descriptor-property-replacement" => true,
"spec-descriptor-property-replacement" => false, {code}
In the persistence.xml for example, there is a freeform <properties> with
properties that can change over time and default values. If *property-replacement is
false , then ${...} is passed to the DUP to configure and can cause problems such as in
this hibernate property which changed from default value of false to true and the user was
unaware that system property substitution was not occurring because they had not enabled
it.
{code:java}
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
<persistence-unit name=“example” transaction-type="JTA">
<jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
<properties>
<property name="hibernate.cache.use_second_level_cache"
value="${hibernate_cache.enabled:false}" />
</properties>
</persistence-unit>
</persistence> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)