[JBoss AS7 Development] - Re: JBoss AS7: Brainstorm Admin Console Security Tab
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] created the discussion
"Re: JBoss AS7: Brainstorm Admin Console Security Tab"
To view the discussion, visit: http://community.jboss.org/message/636025#636025
--------------------------------------------------------------
> Anil Saldhana wrote:
>
> Security Domains need to have CRUD capabilities. The CRUD should not require server restart.
Just a note that my refactor adds the ability to restart a domain without requiring a restart but that means any service which depends on that security domain (perhaps a deployment) will be restarted as well. For this reason the default is to put the server in a state where it must be restarted at the next opportunity for the change to take affect.
If the console passes the ALLOW_RESOURCE_SERVICE_RESTART operation header, which is intended to be triggered by some checkbox or dialog that tells the user what that action means, then the doman service will bounce.
If however, the pbox impl is extended to support hot runtime updates in the futrue, we can replace the restart stuff with that.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/636025#636025]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[JBoss Transactions Development] - XTSTestingCurrentStatus
by Paul Robinson
Paul Robinson [http://community.jboss.org/people/paul.robinson] modified the document:
"XTSTestingCurrentStatus"
To view the document, visit: http://community.jboss.org/docs/DOC-17242
--------------------------------------------------------------
h1. XTS Testing
h1. Current Status and Roadmap
h1.
This Document describes the current status of the XTS tests and what technology they use. There are currently three sets of tests, Unit, Interop and recovery. Each of these is described in turn, and a list of required improvements is presented.
All improvements are targeted at Narayana 5.x unless specified otherwise.
h2. Unit tests
Each XTS component has a set of unit tests. These tests need to be ran within an instance of JBoss AS. These tests are fully automated by an Ant script ran by Hudson.
h3. Improvements
*High Priority (EAP 6.0)*
1. *Ensure AS 7 compatibility.* See issue JBTM-900 (https://issues.jboss.org/browse/JBTM-900).
2. *Move into the AS test suite*. This will ensure that changes to components, we depend upon (like JbossWS), that break XTS are spotted at QE time rather than after release. (EAP 6 requirement). https://issues.jboss.org/browse/JBQA-5191 JBQA-5191
3. *Additional Testing*. XTS Demo tests https://issues.jboss.org/browse/JBQA-5194 JBQA-5194
*Medium Priority (Narayana 5, EAP 7)*
1. *Automate Emma and collate results*. Emma should be used to obtain coverage stats on the test run. Emma, produces individual reports per test, by default. It would be better to have these reports combined as we are concerned with the overall test coverage, rather than the coverage of each test. Ideally we would combine coverage stats over all sets of tests (unit, interop and recovery). Next step would be to improve the coverage where necessary. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority* *(**Narayana 5, EAP 7**)*
1. *Migrate to Maven*. For consistency with rest of the Narayna project. https://issues.jboss.org/browse/JBTM-945 JBTM-945
2. *Update to use Arquillian*. This would mean that that they can be ran from anywhere that can run JUnit tests, such as an IDE or maven. It would also automate the app server lifecycle and test deployment. https://issues.jboss.org/browse/JBTM-954 JBTM-954
3. *Remove home-brew SOAP stack*. In the past these tests used a mock/simple SOAP stack developed specifically for the tests. This stack is no longer used as the tests run within JBoss AS. This code is redundant and should be removed. https://issues.jboss.org/browse/JBTM-953 JBTM-953
h2. Interop Tests
We have two sets of interop tests that live in "XTS/interop". These are built with ant. They are each ran by deploying them as a war to a single JBoss instance which deploys the services needed by the test. This war also exposes a web interface that on request runs the tests and relays the results in the http response.
This process is automated by using ant to deploy the war and then making the http request and validating the response. See here in code for scripts: “XTS/localjunit/run-interop-tests.xml” and “XTS/localjunit/run-tests.xml”
h3. Improvements
*High Priority (EAP 6.0)*
1. *Ensure AS 7 compatibility.* See issue JBTM-905 (https://issues.jboss.org/browse/JBTM-905).
2. *Move into the AS test suite*. https://issues.jboss.org/browse/JBQA-5192 JBQA-5192
*Medium Priority (**Narayana 5, EAP 7**)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (**Narayana 5, EAP 7**)*
1. *Update to use Arquillian*. https://issues.jboss.org/browse/JBTM-955 JBTM-955 https://issues.jboss.org/browse/JBTM-956 JBTM-956
2. *Migrate to Maven*. https://issues.jboss.org/browse/JBTM-943 JBTM-943
h2. Recovery Tests
The recovery tests are the tricky ones. At the moment we have a set of test scenarios that run in a single JBoss server invoked by a remote client. There are also a set of Byteman scripts that trigger failure at certain points in a scenario. There are many different permutations of scenario and Byteman scripts that each create a particular test.
The test scenarios log their progress through the protocol and recovery. On completion of a test run, a human needs to look over the trace and check that it looks right. This process is hard to automate as the trace produced can have many valid interleavings. This is due to the asynchronous nature of the application.
These tests are automated with a bash script, but the output traces must be verified manually by a human. The other problem is that they currently run in a single JBoss server which simulates the situation where every party in the protocol is located in the same app server and crashes & recovers at the same time (not that realistic!). In order to test with multiple servers. we would need a way of combining the traces from each server when verifying the outcome of the test. This could be done by implementing a Byteman helper class, but it would not be trivial.
h3. Improvements
*High Priority (EAP 6.0)*
1. *Move into AS test suite*. The tests are unlikely to be accepted in their current form, due to the level of manual intervention required. This improvement can not be made until we have sufficiently automated the process.
2. *Ensure AS 7 compatibility.* https://issues.jboss.org/browse/JBTM-923 JBTM-923
3. *Automate running*. Use Arquillian to automate the tests and generate trace output for human verification. https://issues.jboss.org/browse/JBQA-3926 JBQA-3926 https://issues.jboss.org/browse/JBTM-817 JBTM-817
*Medium priority (**Narayana 5, EAP 7**)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (**Narayana 5, EAP 7**)
*
1. *Migrate to Maven.* https://issues.jboss.org/browse/JBTM-944 JBTM-944*
*
2. *Automate verification*. Remove the human verification steps. https://issues.jboss.org/browse/JBTM-949 JBTM-949
3. *Multiple Server Tests*. If step 2) is successful, we could be able to build the more complex scenarios where each party runs in its own JBoss server. https://issues.jboss.org/browse/JBTM-950 JBTM-950
4. *Additional Tests*. Andrew Dinn has provided a set of additional tests for us to consider implementing. These should be considered alongside the Emma coverage data for future work. https://issues.jboss.org/browse/JBTM-951 JBTM-951
h2.
h2. Notes
* Arquillian supports multiple JBoss servers:* https://docs.jboss.org/author/display/ARQ/Multiple+Containers https://docs.jboss.org/author/display/ARQ/Multiple+Containers
* Arquillian doesn't yet support servers that crash. This feature is unlikely to make it into EAP 6.* https://issues.jboss.org/browse/ARQ-336 https://issues.jboss.org/browse/ARQ-336
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17242]
Create a new document in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 5 months
[JBoss AS7 Development] - Generic type CLI commands
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/aloubyansky] modified the document:
"Generic type CLI commands"
To view the document, visit: http://community.jboss.org/docs/DOC-16981
--------------------------------------------------------------
A type generic command is a command that is assigned to a specific node type and which allows to perform any operation and/or modify any of the properties exposed by the type on any existing instance of that type.
For example, suppose there is a generic type command assigned to type /subsystem=datasources/data-source and is named data-source. Now using data-source command we can invoke any operation available for children of /subsystem=datasources/data-source and modify any of their properties (that have access-type read-write). The only thing left is to identify the target datasource instance. The way the target is identified depends on a specific command but can be either:
- by choosing one of the read-only properties exposed by the type to be the identifying property;
- by using the name if the instance, i.e. the last node name in the complete node path of the target instance.
In case of the data-source, let's say we decided to use the jndi-name property as the identifying property.
Now you can invoke operations on data sources like this
[standalone@localhost:9999 /] data-source flush-all-connection-in-pool --jndi-name=myds
flush-all-connection-in-pool is an operation name which is exposed by the management model for all datasources and jndi-name argument identifies the datasource flush-all-connection-in-pool should be performed on.
(If we didn't choose jndi-name or any other property as the identifying one then we would have to use the name, i.e. the second way of the identification
{code}
[standalone@localhost:9999 /] data-source flush-all-connection-in-pool --name=myds{code}
)
If the operation we want to perform requires properties, the properties can be added as command line arguments, i.e. here is an example of adding a new datasource
[standalone@localhost:9999 /] data-source add --jndi-name=myds --driver-name=h2 --pool-name=myds-pool --connection-url=curl
add is an operation name and the argument names match the operation property names prefixed with '--'.
Node properties can be modified in a similar way. Property names prefixed with '--' become arguments names. Except here we don't need an operation name, just the identifying property, i.e. the jndi-name in our case (which is a read-only property). E.g.
[standalone@localhost:9999 /] data-source --jndi-name=myds --min-pool-size=11 --max-pool-size=22
The examples above are actually for standalone mode. Commands that handle resources whose node paths don't depend on a specific mode (standalone or domain) will also have no differences in either mode. But if the target resource's node path, like the data-source's, will require the profile part in the domain mode, the command will require one more argument - --profile. E.g.
[domain@localhost:9999 /] data-source --profile=default --jndi-name=myds --min-pool-size=11 --max-pool-size=22
h3. Getting help
Generic type commands support --help option. The help content is generated for each command with data pulled from the management model and is based on the descriptions of the node type, operations and properties it exposes. E.g.
[domain@localhost:9999 /] data-source --help
SYNOPSIS
data-source --help [--properties | --commands] |
--jndi-name=<value> --<property>=<value> (--<property>=<value>)* |
<command> --jndi-name=<value> (--<parameter>=<value>)*
DESCRIPTION
The command is used to manage resources of type /subsystem=datasources/data-source.
RESOURCE DESCRIPTION
(Execute 'data-source --profile=<profile_name> --help' to include the resource description here.)
ARGUMENTS
--help - prints this content.
--help --properties - prints the list of the resource properties including their access-type
(read/write/metric), value type, and the description.
--help --commands - prints the list of the commands available for the resource.
To get the complete description of a specific command (including its parameters,
their types and descriptions), execute data-source <command> --help.
--jndi-name - corresponds to a property of the resourse which
is used to identify the resourse against which the command should be executed.
<property> - property name of the resourse whose value should be updated.
For a complete list of available property names, their types and descriptions,
execute data-source --help --properties.
<command> - command name provided by the resourse. For a complete list of available commands,
execute data-source --help --commands.
<parameter> - parameter name of the <command> provided by the resourse.
For a complete list of available parameter names of a specific <command>,
their types and descriptions, execute data-source <command> --help.
Note, since the command was executed in the domain mode, the resource type description is missing. It couldn't be fetched since the resourc'e path requires the profile specification. If you add --profile argument with the target profile name the description will be complete.
In the standalone mode, the description will appear complete by default.
The following wil list all the properties and their descriptions (datasources hava lots of properties, so I'll paste only an exerpt here)
[standalone@localhost:9999 /] data-source --help --properties
--jndi-name - (STRING,read-write) Specifies the JNDI name for the datasource. Required argument in commands which identifies the instance to execute the command against. --connection-url - (STRING,read-write) The JDBC driver connection URL --driver-name - (STRING,read-write) Defines the JDBC driver the datasource should use. It is a symbolic name matching the the name of installed driver. In case the driver is deployed as jar, the name is the name of deployment unit --pool-name - (STRING,read-write) Specifies the pool name for the datasource used for management --driver-class - (STRING,read-write) The fully qualifed name of the JDBC driver class.
And this is how to list the operations that can be invoked on an instance of the type (btw, this list excludes some operations like
read-attribute, read-children-names, read-children-resources, read-children-types, read-operation-description, read-operation-names, read-resource, read-resource-description, validate-address, write-attribute)
[standalone@localhost:9999 /] data-source --help --commands
add
disable
enable
flush-all-connection-in-pool
flush-idle-connection-in-pool
remove
test-connection-in-pool
To read the description of a specific command execute 'data-source command_name --help'.
Here is an example of the add operation description (again, it accepts a lot of properties, most of which are optional, so I paste only an exerpt of the complete description here)
DESCRIPTION:
Adds a new data-source
REQUIRED ARGUMENTS:
--jndi-name - (STRING) Specifies the JNDI name for the datasource. Required argument in commands which identifies the instance to execute the command against.
--connection-url - (STRING) The JDBC driver connection URL
--driver-name - (STRING) Defines the JDBC driver the datasource should use. It is a symbolic name matching the the name of installed driver. In case the driver is deployed as jar, the name is the name of deployment unit
--pool-name - (STRING) Specifies the pool name for the datasource used for management
OPTIONAL ARGUMENTS:
--driver-class - (STRING) The fully qualifed name of the JDBC driver class
--datasource-class - (STRING) The fully qualifed name of the JDBC datasource class
--new-connection-sql - (STRING) Specifies an SQL statement to execute whenever a connection is added to the connection pool.
h3.
h3. Managing commands
Generic type commands can be added and removed at runtime. There is a command called 'command' which can add new, list and remove existing generic type commands (but not other commands). For example
[standalone@localhost:9999 /] command list
jms-queue data-source connection-factory xa-data-source jms-topic
To add a new command, you need to identify the node type, choose the identifying property and the name for the command. E.g.
[standalone@localhost:9999 /] command add --node-type=subsystem=resource-adapters/resource-adapter --property-id=archive --command-name=resource-adapter
[standalone@localhost:9999 /] command list
jms-queue data-source connection-factory xa-data-source jms-topic resource-adapter
Now there is resource-adapter command which can be used as any other CLI command, e.g.
[standalone@localhost:9999 /] resource-adapter --help --commands
add
flush-all-connection-in-pool
flush-idle-connection-in-pool
remove
test-connection-in-pool
To read the description of a specific command execute 'resource-adapter command_name --help'.
The command can be remove like this
[standalone@localhost:9999 /] command remove --command-name=resource-adapter
[standalone@localhost:9999 /] command list
data-source
NOTE: chnages made to generic type commands don't survive CLI restart yet.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16981]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 5 months