December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-459: ----------------------------------------- Alexey, I'm happy to do the coding work on this or to find someone else to do it, but for sure I wanted to get your inputs regarding what should be done, so I assigned it to you. > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Beta1 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-459: --------------------------------------- Summary: Account for attribute groups in CLI behavior Key: WFCORE-459 URL: https://issues.jboss.org/browse/WFCORE-459 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Brian Stansberry Assignee: Alexey Loubyansky Fix For: 1.0.0.Beta1 See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html This JIRA is for reflecting the attribute group notion in CLI behavior. I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-458) Operations to read attribute group information

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-458?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFCORE-458: ------------------------------------ I assume {{read-attribute-group-names}} return a flat list, rather some form of hierarchy, in the event of nested attribute groups. > Operations to read attribute group information > ---------------------------------------------- > > Key: WFCORE-458 > URL: https://issues.jboss.org/browse/WFCORE-458 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > See "Part III Other possible things to do" in http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html, and Heiko Braun's response thereto. > 1) Add global operation "read-attribute-group(name=<name_of_group>) which functions similarly to read-resource, but only includes in the response those attributes defined as belonging to attribute group "name_of_group". > Besides, the "name" parameter above, parameters and effect thereof should be consistent with "read-resource", except that any parameters dealing with inclusion of child resources should be excluded. > 2) Add global operation "read-attribute-group-names()", which will return a ModelType.LIST whose elements are ModelType.STRING, each element being the name of an attribute-group with which an attribute is associated. Any name only appears once, no entry for the null group to which most attributes belong, response is an empty list if no attribute groups are defined. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-458) Operations to read attribute group information

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-458: --------------------------------------- Summary: Operations to read attribute group information Key: WFCORE-458 URL: https://issues.jboss.org/browse/WFCORE-458 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Fix For: 1.0.0.Beta1 See "Part III Other possible things to do" in http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html, and Heiko Braun's response thereto. 1) Add global operation "read-attribute-group(name=<name_of_group>) which functions similarly to read-resource, but only includes in the response those attributes defined as belonging to attribute group "name_of_group". Besides, the "name" parameter above, parameters and effect thereof should be consistent with "read-resource", except that any parameters dealing with inclusion of child resources should be excluded. 2) Add global operation "read-attribute-group-names()", which will return a ModelType.LIST whose elements are ModelType.STRING, each element being the name of an attribute-group with which an attribute is associated. Any name only appears once, no entry for the null group to which most attributes belong, response is an empty list if no attribute groups are defined. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4173?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4173: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1172856 > Server side EJB Handler not compression response > ------------------------------------------------ > > Key: WFLY-4173 > URL: https://issues.jboss.org/browse/WFLY-4173 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: David Lloyd > > When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response. > On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request > TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream > Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b > TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4173) Server side EJB Handler not compression response

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-4173: ---------------------------------- Summary: Server side EJB Handler not compression response Key: WFLY-4173 URL: https://issues.jboss.org/browse/WFLY-4173 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.0.Alpha1 Reporter: Brad Maxwell Assignee: David Lloyd When compression is enabled for request/response, the jboss-ejb-client is sending a compressed request, but the application server is responding with an uncompressed response. On the server enabling TRACE on org.jboss.as.ejb3, we can see the server receives a compressed request TRACE [org.jboss.as.ejb3] (default task-5) Got message with header 0x1b on channel Channel ID 56b01772 (inbound) of Remoting connection TRACE [org.jboss.as.ejb3.invocation] (default task-5) Received a compressed message stream Client side, Enabling TRACE on the client side for org.jboss.ejb.client we see it is 0x5 where it should be 0x1b TRACE org.jboss.ejb.client.remoting.ChannelAssociation - Received message with header 0x5 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-457) Attribute group basics

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-457: --------------------------------------- Summary: Attribute group basics Key: WFCORE-457 URL: https://issues.jboss.org/browse/WFCORE-457 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Beta1 Basic elements of "attribute group" handling as discussed on the wildfly-dev list in the thread starting at http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html This JIRA is for the non-CLI aspects of the "Part II Proposed Work" section of that email. The CLI ls -l aspect, as well as items in the "PART III Other possible things to do" section are not included. Separate JIRAs will be filed for such things. Specifically, this covers: 1) The basics We add a piece of metadata to the read-resource-description output for an attribute. Name is 'attribute-group', value type is ModelType.STRING, value is the name of the group, with 'undefined' allowed. The group is simply the set of attributes that share the same string. To implement this, we add public String AttributeDefinition.getAttributeGroup() and add support for setting it to the relevant Builder. AttributeDescription.getNoTextDescription outputs the value when it gets called by handlers for read-resource-description and read-operation-description. 2) XML parsing/marshalling Modify PersistentResourceXMLDescription such that attributes in an attribute group get persisted in their own child element, whose name is the name of the group. PersistentResourceXMLBuilder exposes a setter to allow users to turn this on/off for that resource. Turning it off will allow the addition of attribute group settings for a resource without requiring an immediate corresponding xsd change. 3) Low level management API The output of read-resource and read-resource-description is modified such that attributes are sorted by group name and then by attribute name. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1594) Domain Management logout 'feature' not working for HTTP BASIC authentication.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1594: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=976917, https://bugzilla.redhat.com/show_bug.cgi?id=1051189, https://bugzilla.redhat.com/show_bug.cgi?id=1074849 (was: https://bugzilla.redhat.com/show_bug.cgi?id=976917, https://bugzilla.redhat.com/show_bug.cgi?id=1051189) > Domain Management logout 'feature' not working for HTTP BASIC authentication. > ----------------------------------------------------------------------------- > > Key: WFLY-1594 > URL: https://issues.jboss.org/browse/WFLY-1594 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment status is FAILED but application running well

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-880: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059842 > jboss-cli.sh show deployment status is FAILED but application running well > -------------------------------------------------------------------------- > > Key: WFLY-880 > URL: https://issues.jboss.org/browse/WFLY-880 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Environment: suse linux 11 sp2 > Reporter: jing chen > Assignee: Richard Opalka > Labels: jboss > Fix For: 8.0.0.Alpha2 > > > run jboss-cli.sh to check the deployment status and it shows FAILED. > NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)" > { > "outcome" => "success", > "result" => "FAILED" > } > nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1511) RemoteDomainConnection.close() will block forever if the master HC is not running

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1511: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012850, https://bugzilla.redhat.com/show_bug.cgi?id=1153383, https://bugzilla.redhat.com/show_bug.cgi?id=1045634 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1012850, https://bugzilla.redhat.com/show_bug.cgi?id=1153383) > RemoteDomainConnection.close() will block forever if the master HC is not running > ---------------------------------------------------------------------------------- > > Key: WFLY-1511 > URL: https://issues.jboss.org/browse/WFLY-1511 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.Beta1 > > > RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality. > Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/ > That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2014