[JBoss JIRA] (WFCORE-3062) Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3062?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3062:
------------------------------------------
You're welcome Stefan. It's a flaw using the same AttributeDefinition class(es) for all these different things since it makes it unclear what settings are valid in which use cases.
> Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3062
> URL: https://issues.jboss.org/browse/WFCORE-3062
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta28
> Reporter: Stefan Guilhen
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta29
>
>
> When reading the description of attributes of type OBJECT, the access constraints of the value types contained in the object attribute are not displayed.
> Example: In BaseHttpInterfaceResourceDefinition we have an http-upgrade attribute of type OBJECT that contains the sasl-authentication-factory attribute, which is a simple attribute with an access constraint.
> When running /core-service=management/management-interface=http-interface:read-resource-description(recursive=true) in the CLI the constraint is not displayed for the attribute:
> {noformat}
> "http-upgrade" => {
> "type" => OBJECT,
> "description" => "HTTP Upgrade specific configuration",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "value-type" => {
> "enabled" => {
> "type" => BOOLEAN,
> "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => false
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9175) IJ000311: Throwable from unregister connection
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9175?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9175:
--------------------------------------
Component/s: JCA
Assignee: Stefano Maestri (was: Jason Greene)
> IJ000311: Throwable from unregister connection
> ----------------------------------------------
>
> Key: WFLY-9175
> URL: https://issues.jboss.org/browse/WFLY-9175
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: junot dutra lira
> Assignee: Stefano Maestri
>
> I have a java web project with jsf + primefaces running in wildfly, noticed some error messages in the log, I did not find any solution to this, it follows a part of the log:
> 2017-08-03 10:55:56,747 INFO [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (default task-56) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4d230e4e
> at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
> at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.closeConnection(DatasourceConnectionProviderImpl.java:127)
> at org.hibernate.internal.NonContextualJdbcConnectionAccess.releaseConnection(NonContextualJdbcConnectionAccess.java:46)
> at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:189)
> at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:155)
> at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:282)
> at org.hibernate.internal.SessionImpl.afterOperation(SessionImpl.java:534)
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1455)
> at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1402)
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1374)
> at org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1420)
> at org.hibernate.query.criteria.internal.compile.CriteriaQueryTypeQueryAdapter.getSingleResult(CriteriaQueryTypeQueryAdapter.java:59)
> at br.gov.ms.drap.dao.armamento.ArmaDao.buscaArmaById(ArmaDao.java:58)
> at br.gov.ms.drap.bean.armamento.ArmaManagedBean.consultar(ArmaManagedBean.java:119)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at javax.el.ELUtil.invokeMethod(ELUtil.java:300)
> at javax.el.BeanELResolver.invoke(BeanELResolver.java:415)
> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
> at com.sun.el.parser.AstValue.invoke(AstValue.java:285)
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
> at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:147)
> at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
> at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:814)
> at javax.faces.component.UICommand.broadcast(UICommand.java:300)
> at javax.faces.component.UIData.broadcast(UIData.java:1108)
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:78)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at br.gov.ms.drap.filter.FiltroLogin.doFilter(FiltroLogin.java:128)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3062) Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3062?page=com.atlassian.jira.plugi... ]
Stefan Guilhen commented on WFCORE-3062:
----------------------------------------
Brian, thanks for looking into this and also for the thorough explanation of the issue. I didn't really know how the access constraints in the fields contained in ModelType.OBJECT attributes were processed so I coded what I thought would be a quick fix.
> Access constraints are not displayed for value types contained in ObjectTypeAttributeDefinition
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3062
> URL: https://issues.jboss.org/browse/WFCORE-3062
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta28
> Reporter: Stefan Guilhen
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta29
>
>
> When reading the description of attributes of type OBJECT, the access constraints of the value types contained in the object attribute are not displayed.
> Example: In BaseHttpInterfaceResourceDefinition we have an http-upgrade attribute of type OBJECT that contains the sasl-authentication-factory attribute, which is a simple attribute with an access constraint.
> When running /core-service=management/management-interface=http-interface:read-resource-description(recursive=true) in the CLI the constraint is not displayed for the attribute:
> {noformat}
> "http-upgrade" => {
> "type" => OBJECT,
> "description" => "HTTP Upgrade specific configuration",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "value-type" => {
> "enabled" => {
> "type" => BOOLEAN,
> "description" => "Flag that indicates HTTP Upgrade is enabled, which allows HTTP requests to be upgraded to native remoting connections",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => false
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1071) NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1071?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on DROOLS-1071 at 8/3/17 2:15 PM:
------------------------------------------------------------------
To have a line number (of the DRL source file) we'd need to do a similar trick as how JSP's stacktraces are translated back to JSP source file line numbers (thanks to Tomaz for info). This technique is known as "source maps".
{quote}
The JSP compiler jastow (fork of tomcat's jasper) does this:
https://github.com/undertow-io/jastow
what you are looking for is "smap" generation and applying to compiler:
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
{quote}
was (Author: ge0ffrey):
To have a line number (of the DRL source file) we'd need to do a similar trick as how JSP's stacktraces are translated back to JSP source file line numbers (thanks to Tomaz for info).
{quote}
The JSP compiler jastow (fork of tomcat's jasper) does this:
https://github.com/undertow-io/jastow
what you are looking for is "smap" generation and applying to compiler:
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
https://github.com/undertow-io/jastow/blob/master/src/main/java/org/apach...
{quote}
> NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1071
> URL: https://issues.jboss.org/browse/DROOLS-1071
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Beta2
> Environment: JDK: Java 7
> OS: Mac OSX 10.10.2
> IDE: Spring Tool Suite 3.6.4
> Reporter: Ido Flax
> Assignee: Mario Fusco
> Fix For: 6.5.0.Final, 7.0.0.Beta2
>
> Attachments: AbstractPlannerDto.java, EquipmentEquipmentTypesPlannerDto.java, LabourDayOffPlannerDto.java, OnHandForProduct.java, ProductInventoryTransactionPlannerDto.java, ProductPlannerDto.java, SkillsAndRatesPlannerDto.java, TaskPlannerDto.java, TaskResourceAllocationPlannerDto.java, TaskResourcePlannerDto.java, UserPlannerDto.java, activity-scoring.drl
>
>
> The attached code generates an NPE when running optaplanner/drools, but that stacktrace doesn't tell me which DRL line is responsible for it.
> Stacktrace:
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at ConditionEvaluatoreaa3997683d949e28ce6eaf6feca0ced.evaluate(Unknown Source) <================ No source DRL line
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:226)
> at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:111)
> at org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:112)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:75)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:369)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:329)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:120)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:84)
> at org.optaplanner.core.impl.solver.recaller.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:70)
> at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:197)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:175)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3144) Upgrade VDX from 1.1.5 to 1.1.6
by James Perkins (JIRA)
James Perkins created WFCORE-3144:
-------------------------------------
Summary: Upgrade VDX from 1.1.5 to 1.1.6
Key: WFCORE-3144
URL: https://issues.jboss.org/browse/WFCORE-3144
Project: WildFly Core
Issue Type: Component Upgrade
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
Priority: Blocker
Fix For: 3.0.0.CR1
Upgrade VDX from 1.1.5 to 1.1.6.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9178) Attempting to access the admin console on Edge doesn't request user/password auth
by Robert Robert (JIRA)
Robert Robert created WFLY-9178:
-----------------------------------
Summary: Attempting to access the admin console on Edge doesn't request user/password auth
Key: WFLY-9178
URL: https://issues.jboss.org/browse/WFLY-9178
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 10.1.0.Final
Environment: Windows 10
Reporter: Robert Robert
Assignee: Harald Pehl
Priority: Minor
When attempting to access http://localhost:9990/ with a Wildfly 10.1.0 instance running the default standalone.xml config and a simple Management user added, the user is immediately greeted with:
The management interface could not be loaded.
Authentication required.
However, when I try this same URL on Chrome, Chrome requests a user and password authentication request and is able to login.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9176) Inefficient use of OperationContext.readResourceFromRoot
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9176:
--------------------------------------
Summary: Inefficient use of OperationContext.readResourceFromRoot
Key: WFLY-9176
URL: https://issues.jboss.org/browse/WFLY-9176
Project: WildFly
Issue Type: Bug
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The single param OperationContext.readResourceFromRoot(...) variant can be quite expensive, as can be the 2 param variant if the 'recursive' param is true. The op returns a clone of the management model, and creating the clone can be expensive if the cloning is recursive and the affected tree is large.
There are a lot of calls like this in full WildFly that look like they could use the 2 param variant with recursive = false. Some of these are cloning the entire resource tree.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9177) Inefficient use of OperationContext.readResourceFromRoot
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-9177:
--------------------------------------
Summary: Inefficient use of OperationContext.readResourceFromRoot
Key: WFLY-9177
URL: https://issues.jboss.org/browse/WFLY-9177
Project: WildFly
Issue Type: Bug
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The single param OperationContext.readResourceFromRoot(...) variant can be quite expensive, as can be the 2 param variant if the 'recursive' param is true. The op returns a clone of the management model, and creating the clone can be expensive if the cloning is recursive and the affected tree is large.
There are a lot of calls like this in full WildFly that look like they could use the 2 param variant with recursive = false. Some of these are cloning the entire resource tree.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months