[JBoss JIRA] (ELY-1593) Coverity static analysis, Resource leak on the exceptional path of setFile in FileAuditEndpoint
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1593?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev commented on ELY-1593:
------------------------------------
Not a bug. When {{fos.getFD()}} throws an exception, ok flag is false and we close the resources in the {{finally}} blocks.
> Coverity static analysis, Resource leak on the exceptional path of setFile in FileAuditEndpoint
> -----------------------------------------------------------------------------------------------
>
> Key: ELY-1593
> URL: https://issues.jboss.org/browse/ELY-1593
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Audit
> Affects Versions: 1.3.2.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> Coverity static analysis found possible occurrence of resource leak.
> https://scan7.coverity.com/reports.htm#v20225/p11778/fileInstanceId=53592...
> When {{fos.getFD()}} will throw exception {{FileOutputStream fos}} won't be closed.
> {code:java|title=FileAuditEndpoint.java}
> void setFile(final File file) throws IOException {
> boolean ok = false;
> final FileOutputStream fos = new FileOutputStream(file, true);
> try {
> final OutputStream bos = new BufferedOutputStream(fos);
> try {
> this.fileDescriptor = fos.getFD();
> this.outputStream = bos;
> this.file = file;
> ok = true;
> } finally {
> if (! ok) {
> safeClose(bos);
> }
> }
> } finally {
> if (! ok) {
> safeClose(fos);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1593) Coverity static analysis, Resource leak on the exceptional path of setFile in FileAuditEndpoint
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1593?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev edited comment on ELY-1593 at 5/25/18 1:21 PM:
-------------------------------------------------------------
Not a bug. When {{fos.getFD()}} throws an exception, {{ok}} flag is false and we close the resources in the {{finally}} blocks.
was (Author: ivassile):
Not a bug. When {{fos.getFD()}} throws an exception, ok flag is false and we close the resources in the {{finally}} blocks.
> Coverity static analysis, Resource leak on the exceptional path of setFile in FileAuditEndpoint
> -----------------------------------------------------------------------------------------------
>
> Key: ELY-1593
> URL: https://issues.jboss.org/browse/ELY-1593
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Audit
> Affects Versions: 1.3.2.Final
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
>
> Coverity static analysis found possible occurrence of resource leak.
> https://scan7.coverity.com/reports.htm#v20225/p11778/fileInstanceId=53592...
> When {{fos.getFD()}} will throw exception {{FileOutputStream fos}} won't be closed.
> {code:java|title=FileAuditEndpoint.java}
> void setFile(final File file) throws IOException {
> boolean ok = false;
> final FileOutputStream fos = new FileOutputStream(file, true);
> try {
> final OutputStream bos = new BufferedOutputStream(fos);
> try {
> this.fileDescriptor = fos.getFD();
> this.outputStream = bos;
> this.file = file;
> ok = true;
> } finally {
> if (! ok) {
> safeClose(bos);
> }
> }
> } finally {
> if (! ok) {
> safeClose(fos);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3891) Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3891?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3891:
---------------------------------------
This is due to the {{named-formatter}} attribute being undefined. When left undefined the {{formatter}} attribute is used and a new {{org.jboss.logmanager.formatters.PatternFormatter}} is created with the name of the handler. Since the handler is named {{test}} it creates a new pattern formatter configuration named {{test}} which is why the {{pattern-formatter}} works yet other formatters do not.
The simplest workaround is just to define the {{named-formatter}} attribute. You can also add a {{pattern-formatter}}, remove it, then add a new JSON or XML formatter with the same name. Though I'd likely consider that a bug too since it leaves the handler with no formatter assigned.
This is somewhat related to WFCORE-3337 as logging really should be using capabilities to wire some validation into the configuration API. Some of this can be handled with LOGMGR-179 however it would be a lot cleaner and result in better error messages to use capabilities.
> Cannot create xml-formatter and json-formatter with the same name as existing resources in logging subsystem
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3891
> URL: https://issues.jboss.org/browse/WFCORE-3891
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Nikoleta Žiaková
> Assignee: James Perkins
>
> When trying to create an {{xml-formatter}} or {{json-formatter}} with the same name as another resource (e.g. a {{file-handler}}), the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=aaa.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/xml-formatter=test:add
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"dateFormat\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> Similarly vice-versa, when trying to create another resource in logging subsystem with the same name as an {{xml-formatter}} or a {{json-formatter}}, the operation fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/json-formatter=test:add
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No property \"pattern\" setter found for formatter \"test\"",
> "rolled-back" => true
> }
> {code}
> The same scenario works for e.g. {{pattern-formatter}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/file-handler=test:add(file={path=test.log})
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=logging/pattern-formatter=test:add
> {"outcome" => "success"}
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9622) Eliminate uses of ModelNode.resolve()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9622?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9622:
----------------------------------------
BTW [~rhusar] I don't know what you're doing in your WFLY-10439 branch re ProxyListValidator, but its impl of validateResolvedParameter can (should) just be deleted and the default impl in the interface used. That interface method is no longer used.
> Eliminate uses of ModelNode.resolve()
> -------------------------------------
>
> Key: WFLY-9622
> URL: https://issues.jboss.org/browse/WFLY-9622
> Project: WildFly
> Issue Type: Task
> Components: Clustering, JCA, JMS, JPA / Hibernate, Management, mod_cluster
> Reporter: Brian Stansberry
>
> Code inspection shows there are 16 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 4 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.
> Current uses:
> {code}
> Method
> resolve()
> Found usages (16 usages found)
> Production (12 usages found)
> Unclassified usage (12 usages found)
> wildfly-connector (3 usages found)
> org.jboss.as.connector.subsystems.common.pool (2 usages found)
> PoolConfigurationRWHandler.PoolConfigurationWriteHandler (1 usage found)
> revertUpdateToRuntime(OperationContext, ModelNode, String, ModelNode, ModelNode, List<PoolConfiguration>) (1 usage found)
> 126 updatePoolConfigs(handback, parameterName, valueToRestore.resolve());
> PoolStatisticsRuntimeAttributeWriteHandler (1 usage found)
> execute(OperationContext, ModelNode) (1 usage found)
> 58 final ModelNode resolvedValue = newValue.resolve();
> org.jboss.as.connector.subsystems.datasources (1 usage found)
> Constants (1 usage found)
> 297 validateParameter(parameterName, value.resolve());
> wildfly-jpa (4 usages found)
> org.jboss.as.jpa.management (1 usage found)
> ManagementResourceDefinition (1 usage found)
> registerAttributes(ManagementResourceRegistration) (1 usage found)
> 154 final ModelNode value = operation.get(ModelDescriptionConstants.VALUE).resolve();
> org.jboss.as.jpa.subsystem (3 usages found)
> JPASubSystemAdd (3 usages found)
> performBoottime(OperationContext, ModelNode, ModelNode) (3 usages found)
> 78 runtimeValidator.validate(operation.resolve());
> 125 final String dataSourceName = defaultDSNode.resolve().asString();
> 131 ExtendedPersistenceInheritance.valueOf(defaultExtendedPersistenceInheritanceNode.resolve().asString());
> wildfly-messaging-activemq (4 usages found)
> org.wildfly.extension.messaging.activemq.deployment (4 usages found)
> MessagingXmlInstallDeploymentUnitProcessor (4 usages found)
> deploy(DeploymentPhaseContext) (4 usages found)
> 76 final ModelNode entries = topic.getDestination().resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 97 final ModelNode entries = destination.resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 100 final String selector = destination.hasDefined(SELECTOR.getName()) ? destination.get(SELECTOR.getName()).resolve().asString() : null;
> 101 final boolean durable = destination.hasDefined(DURABLE.getName()) ? destination.get(DURABLE.getName()).resolve().asBoolean() : false;
> wildfly-mod_cluster-extension (1 usage found)
> org.wildfly.extension.mod_cluster (1 usage found)
> ProxyListValidator (1 usage found)
> validateResolvedParameter(String, ModelNode) (1 usage found)
> 59 validateParameter(parameterName, value.resolve());
> Test (4 usages found)
> Unclassified usage (4 usages found)
> wildfly-clustering-jgroups-extension (4 usages found)
> org.jboss.as.clustering.jgroups.subsystem (4 usages found)
> OperationsTestCase (4 usages found)
> testSubsystemReadWriteOperations() (1 usage found)
> 52 Assert.assertEquals("ee", result.get(RESULT).resolve().asString());
> testTransportReadWriteOperation() (1 usage found)
> 75 Assert.assertEquals("rack1", result.get(RESULT).resolve().asString());
> testTransportPropertyReadWriteOperation() (1 usage found)
> 114 Assert.assertEquals("true", result.get(RESULT).resolve().asString());
> testProtocolPropertyReadWriteOperation() (1 usage found)
> 195 Assert.assertEquals("value", result.get(RESULT).resolve().asString());
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9622) Eliminate uses of ModelNode.resolve()
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9622?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9622:
----------------------------------------
Nice; thanks [~rhusar]!
> Eliminate uses of ModelNode.resolve()
> -------------------------------------
>
> Key: WFLY-9622
> URL: https://issues.jboss.org/browse/WFLY-9622
> Project: WildFly
> Issue Type: Task
> Components: Clustering, JCA, JMS, JPA / Hibernate, Management, mod_cluster
> Reporter: Brian Stansberry
>
> Code inspection shows there are 16 uses of ModelNode.resolve() in WildFly's own code base, 12 in production code and 4 in test code. We should eliminate these, as WildFly's expression resolution is more complex than the ModelNode.resolve() contract, including vault support for which its' hard to imagine us wanting support in DMR itself. So these uses should switch to resolution from the OperationContext or, if that's not feasible, e.g. in test code, use something like ExpressionResolver.TEST_RESOLVER.
> Current uses:
> {code}
> Method
> resolve()
> Found usages (16 usages found)
> Production (12 usages found)
> Unclassified usage (12 usages found)
> wildfly-connector (3 usages found)
> org.jboss.as.connector.subsystems.common.pool (2 usages found)
> PoolConfigurationRWHandler.PoolConfigurationWriteHandler (1 usage found)
> revertUpdateToRuntime(OperationContext, ModelNode, String, ModelNode, ModelNode, List<PoolConfiguration>) (1 usage found)
> 126 updatePoolConfigs(handback, parameterName, valueToRestore.resolve());
> PoolStatisticsRuntimeAttributeWriteHandler (1 usage found)
> execute(OperationContext, ModelNode) (1 usage found)
> 58 final ModelNode resolvedValue = newValue.resolve();
> org.jboss.as.connector.subsystems.datasources (1 usage found)
> Constants (1 usage found)
> 297 validateParameter(parameterName, value.resolve());
> wildfly-jpa (4 usages found)
> org.jboss.as.jpa.management (1 usage found)
> ManagementResourceDefinition (1 usage found)
> registerAttributes(ManagementResourceRegistration) (1 usage found)
> 154 final ModelNode value = operation.get(ModelDescriptionConstants.VALUE).resolve();
> org.jboss.as.jpa.subsystem (3 usages found)
> JPASubSystemAdd (3 usages found)
> performBoottime(OperationContext, ModelNode, ModelNode) (3 usages found)
> 78 runtimeValidator.validate(operation.resolve());
> 125 final String dataSourceName = defaultDSNode.resolve().asString();
> 131 ExtendedPersistenceInheritance.valueOf(defaultExtendedPersistenceInheritanceNode.resolve().asString());
> wildfly-messaging-activemq (4 usages found)
> org.wildfly.extension.messaging.activemq.deployment (4 usages found)
> MessagingXmlInstallDeploymentUnitProcessor (4 usages found)
> deploy(DeploymentPhaseContext) (4 usages found)
> 76 final ModelNode entries = topic.getDestination().resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 97 final ModelNode entries = destination.resolve().get(CommonAttributes.DESTINATION_ENTRIES.getName());
> 100 final String selector = destination.hasDefined(SELECTOR.getName()) ? destination.get(SELECTOR.getName()).resolve().asString() : null;
> 101 final boolean durable = destination.hasDefined(DURABLE.getName()) ? destination.get(DURABLE.getName()).resolve().asBoolean() : false;
> wildfly-mod_cluster-extension (1 usage found)
> org.wildfly.extension.mod_cluster (1 usage found)
> ProxyListValidator (1 usage found)
> validateResolvedParameter(String, ModelNode) (1 usage found)
> 59 validateParameter(parameterName, value.resolve());
> Test (4 usages found)
> Unclassified usage (4 usages found)
> wildfly-clustering-jgroups-extension (4 usages found)
> org.jboss.as.clustering.jgroups.subsystem (4 usages found)
> OperationsTestCase (4 usages found)
> testSubsystemReadWriteOperations() (1 usage found)
> 52 Assert.assertEquals("ee", result.get(RESULT).resolve().asString());
> testTransportReadWriteOperation() (1 usage found)
> 75 Assert.assertEquals("rack1", result.get(RESULT).resolve().asString());
> testTransportPropertyReadWriteOperation() (1 usage found)
> 114 Assert.assertEquals("true", result.get(RESULT).resolve().asString());
> testProtocolPropertyReadWriteOperation() (1 usage found)
> 195 Assert.assertEquals("value", result.get(RESULT).resolve().asString());
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1649:
-------------------------------------
Fix Version/s: (was: 5.0.0.CR1)
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10458) CLI description of the byte-buffer-pool max-pool-size attribute contains extra words
by Jan Stourac (JIRA)
Jan Stourac created WFLY-10458:
----------------------------------
Summary: CLI description of the byte-buffer-pool max-pool-size attribute contains extra words
Key: WFLY-10458
URL: https://issues.jboss.org/browse/WFLY-10458
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 13.0.0.Beta1
Reporter: Jan Stourac
Assignee: Stuart Douglas
Priority: Trivial
Description of the {{max-pool-size}} attribute in the {{/subsystem=undertow/byte-buffer-pool}} contains:
{quote}
The maximum amount of buffers to keep in the pool. If more buffers are required at runtime they will be allocated dynamically. Setting this to zero effectively disables pooling. *This allows*
{quote}
There is a fraction of a new sentence at the end. It should be removed, though.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months