[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Will Tatam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Will Tatam commented on WFLY-3636:
----------------------------------
Hi [~jmesnil] could you provide an example of how you get the pool stats? Does this also work in EAP 7.0 ?
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7033) EL break page compilation
by Marco Mondini (JIRA)
[ https://issues.jboss.org/browse/WFLY-7033?page=com.atlassian.jira.plugin.... ]
Marco Mondini updated WFLY-7033:
--------------------------------
Attachment: elfix.patch
This should fix the issue.
> EL break page compilation
> -------------------------
>
> Key: WFLY-7033
> URL: https://issues.jboss.org/browse/WFLY-7033
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Marco Mondini
> Assignee: Tomaz Cerar
> Attachments: elfix.patch
>
>
> In case of an expression with multiple ELs, fix for WFLY-4455 breaks braces precedence.
> As a conseguence, if a single quote is present between expressions, EL Parser can't find function in second expression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1245:
-------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1283294|https://bugzilla.redhat.com/show_bug.cgi?id=1283294] from POST to CLOSED
> Improve readability of missing dependency logs
> ----------------------------------------------
>
> Key: WFCORE-1245
> URL: https://issues.jboss.org/browse/WFCORE-1245
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
> Attachments: after_1.log, after_2.log, before.log, bz1283294-reproducer.zip
>
>
> When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
> Structure of deployment is as follows:
> {noformat}
> reproducer.ear
> |- service-locator.jar
> | |- ServiceLocator (Stateless EJB)
> | |- TestQueue (JNDI Resource)
> |- client.jar
> |- TestEjb (Stateless EJB)
> |- ServiceLocator
> {noformat}
> If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
> When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
> Example with a single dependant EJB:
> {noformat}
> 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1774:
------------------------------------------
[~jdenise] If the tab completion can work based solely on the capability registry and not involving analyzing resource addresses, that is better. It looks like it's possible given the data present in the registry. Please feel free to request server side management API enhancements if they will make it easier, e.g. by reducing the amount of data the CLI needs to pull to calculate the answer.
That said, in the specific example here of a JGroups transport diagnostic-socket-binding attribute, the attribute references capability org.wildfly.network.socket-binding and there the dynamic part of the valid names does not include tcp.TCP, udp.UDP etc.
{code}
[standalone@embedded /] /subsystem=jgroups/stack=udp/transport=UDP:read-resource-description
{
"outcome" => "success",
"result" => {
....
"attributes" => {
....
"diagnostics-socket-binding" => {
"type" => STRING,
"description" => "The diagnostics socket binding specification for this protocol layer, used to specify IP interfaces and ports for communication.",
"expressions-allowed" => true,
"nillable" => true,
"capability-reference" => "org.wildfly.network.socket-binding",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
},
{code}
I don't believe the capability org.wildly.clustering.transport.diagnostics-socket-binding capability is actually meant to be referenced. It would be fairly unfriendly to the users of capabilities named that way were used as reference targets. But, if a developer did that, the way you propose would be the only way I could see to identify the correct candidates.
Re: static capabilities an attribute cannot reference one because the attribute value must point to something dynamic.
> Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1774
> URL: https://issues.jboss.org/browse/WFCORE-1774
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Brian Stansberry
> Assignee: Jean-Francois Denise
>
> A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
> [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though:
> 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
> 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
> That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
> {code}
> [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
> {
> "outcome" => "success",
> "result" => ["/socket-binding-group=*/socket-binding=*"]
> }
> {code}
> That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
> 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
> HAL may be doing something slightly different from what I describe; they have concrete experience.
> It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
> [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7093) Transfer of contextData back to the jboss ejb client
by Teresa Miyar (JIRA)
Teresa Miyar created WFLY-7093:
----------------------------------
Summary: Transfer of contextData back to the jboss ejb client
Key: WFLY-7093
URL: https://issues.jboss.org/browse/WFLY-7093
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Teresa Miyar
Priority: Minor
The spec says:
The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation.
The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression
by Ivo Hrádek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ]
Ivo Hrádek commented on WFCORE-1783:
------------------------------------
[~brian.stansberry] - I've re-implemented PR, as you have suggested.
> CLI GUI throws exception when editing boolean attribute with expression
> -----------------------------------------------------------------------
>
> Key: WFCORE-1783
> URL: https://issues.jboss.org/browse/WFCORE-1783
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: John Mazzitelli
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank.
> See "Steps to Reproduce" for replication procedures.
> Here's the exception:
> java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428)
> at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336)
> at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157)
> at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73)
> at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152)
> at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
> at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
> at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
> at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
> at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
> at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
> at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
> at java.awt.Component.processMouseEvent(Component.java:6535)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6300)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4891)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2750)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1785:
-------------------------------------
Summary: Extension remove is not cleaning out provided capabilities (was: Not possible to add Elytron subsystem after it was previously removed)
> Extension remove is not cleaning out provided capabilities
> ----------------------------------------------------------
>
> Key: WFCORE-1785
> URL: https://issues.jboss.org/browse/WFCORE-1785
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha7
> Reporter: Jan Tymel
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha8
>
>
> It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly.
> Actual result:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.",
> "rolled-back" => true
> }
> {code}
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518)
> at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669)
> at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83)
> at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107)
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226)
> at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694)
> at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
> at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Expected result:
> It is possible to add Elytron subsystem after its removal.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months