[JBoss AS7 Development] - Logging in Core JBoss Application Server 7
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging in Core JBoss Application Server 7"
To view the document, visit: http://community.jboss.org/docs/DOC-17334
--------------------------------------------------------------
h3. *General Rules:*
* All exceptions and messages require a translation method in the @MessageBundle.
* All info and higher messages being logged require a translation method in the @MessageLogger.
* Messages in both the @MessageBundle and @MessageLogger should have an id***. Note though there are cases, specifically some methods in the @MessageBundle, that do not need id's. These typically include messages that are not being used in exceptions.
* All logged messages should use a static logger from the @MessageLogger interface. This includes debug and trace messages.
*** A list of id's can be found here http://community.jboss.org/docs/DOC-16810 http://community.jboss.org/wiki/LoggingIds
h3. Passing the cause:
Both @MessageLogger's and @MessageBundle's can except a java.lang.Throwable type as a parameter to either log the exception or intialize the exception return types cause. This is done by annotating the parameter with @Cause.
StartException unableToStart(@Cause Throwable cause);
h3. Creating Exception Return Types:
Most @MessageBundle's methods will be returing exceptions. Some exceptions require a special constructor to be used or require a property/field to be set on the exception. JBoss Logging has 3 separate annotations for these requirements.
@Param - Is used for exception constructor.
SAXParseException invalidAttribute(@Param Locator locator, String attributeName, String tagName);
@Field({name=fieldName}) - Is used to set an instance variable.
XAException invalidTransaction(@Field Integer errorCode);
@Propert({name=propertyName}) - Is used to set a property via it's setter method.
Exception createException(@Property StackTrace[] stackTrace);
h3.
h3. *Examples:*
*
*
*Before:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw new StartException("Failed to create temp file provider");
}
log.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
*Methods added to DeploymentRepositoryMessages:*
/**
* Creates an exception indicating a failure to create a temp file provider.
*
* @return a {@link StartException} for the error.
*/
@Message(id = 14900, value = "Failed to create temp file provider")
StartException failedCreatingTempProvider();
*After:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw MESSAGES.failedCreatingTempProvider();
}
ROOT_LOGGER.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17334]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Logging for JBoss Application Server 7 Subsystems
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging for JBoss Application Server 7 Subsystems"
To view the document, visit: http://community.jboss.org/docs/DOC-17334
--------------------------------------------------------------
h3. *General Rules:*
* All exceptions and messages require a translation method in the @MessageBundle.
* All info and higher messages being logged require a translation method in the @MessageLogger.
* Messages in both the @MessageBundle and @MessageLogger should have an id***. Note though there are cases, specifically some methods in the @MessageBundle, that do not need id's. These typically include messages that are not being used in exceptions.
* All logged messages should use a static logger from the @MessageLogger interface. This includes debug and trace messages.
*** A list of id's can be found here http://community.jboss.org/docs/DOC-16810 http://community.jboss.org/wiki/LoggingIds
h3. Passing the cause:
Both @MessageLogger's and @MessageBundle's can except a java.lang.Throwable type as a parameter to either log the exception or intialize the exception return types cause. This is done by annotating the parameter with @Cause.
StartException unableToStart(@Cause Throwable cause);
h3. Creating Exception Return Types:
Most @MessageBundle's methods will be returing exceptions. Some exceptions require a special constructor to be used or require a property/field to be set on the exception. JBoss Logging has 3 separate annotations for these requirements.
@Param - Is used for exception constructor.
SAXParseException invalidAttribute(@Param Locator locator, String attributeName, String tagName);
@Field({name=fieldName}) - Is used to set an instance variable.
XAException invalidTransaction(@Field Integer errorCode);
@Propert({name=propertyName}) - Is used to set a property via it's setter method.
Exception createException(@Property StackTrace[] stackTrace);
h3.
h3. *Examples:*
*
*
*Before:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw new StartException("Failed to create temp file provider");
}
log.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
*Methods added to DeploymentRepositoryMessages:*
/**
* Creates an exception indicating a failure to create a temp file provider.
*
* @return a {@link StartException} for the error.
*/
@Message(id = 14900, value = "Failed to create temp file provider")
StartException failedCreatingTempProvider();
*After:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw MESSAGES.failedCreatingTempProvider();
}
ROOT_LOGGER.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17334]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 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 (Post EAP 6)*
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* *(Post EAP 6)*
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 (Post EAP 6.0)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (Post EAP 6.0)*
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 (Post EAP 6.0)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (Post EAP 6.0)
*
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...]
13 years, 2 months
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *
* |
|
| *10600 - 10699* | *Controller Client* |
|
| *10700 - 10799* | *Deployment Repository* |
|
| *10900 - 10999* | *Deployment Scanner* |
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* |
|
| *11200 - 11299* | *JAXRS* |
|
| *11300 - 11399* | *JMX* |
|
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* | I |
| *14400 - 14499* | *AppClient* | C |
| *14500 - 14599* | *JDR* |
|
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | W |
| *15000 - 15099* | *Deployment Scanner* | W |
| *15100 - 15199* | *Deployment HTTP API* | W |
| *15200 - 15299* | *Deployment Management* | W |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 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 (Post EAP 6)*
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* *(Post EAP 6)*
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.
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 (Post EAP 6.0)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (Post EAP 6.0)*
1. *Update to use Arquillian*.
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 (Post EAP 6.0)*
1. *Automate Emma and collate results*. https://issues.jboss.org/browse/JBTM-952 JBTM-952
*Low Priority (Post EAP 6.0)
*
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...]
13 years, 2 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*. https://issues.jboss.org/browse/JBQA-5191 https://issues.jboss.org/browse/JBQA-5191. 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)
3. *Additional Testing*. XTS Demo tests ( https://issues.jboss.org/browse/JBQA-5194 https://issues.jboss.org/browse/JBQA-5194)
*Medium Priority (Post EAP 6)*
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.
*Low Priority* *(Post EAP 6)*
1. *Migrate to Maven*. For consistency with rest of the Narayna project
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.
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.
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 https://issues.jboss.org/browse/JBQA-5192).
*Medium Priority (Post EAP 6.0)*
1. *Automate Emma and collate results*.
*Low Priority (Post EAP 6.0)*
1. *Update to use Arquillian*.
2. *Migrate to Maven*.
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 (Post EAP 6.0)*
1. *Automate Emma and collate results*.
*Low Priority (Post EAP 6.0)
*
1. *Migrate to Maven*
2. *Automate verification*. Remove the human verification steps.
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.
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.
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...]
13 years, 2 months
[JBoss AS7 Development] - Logging for JBoss Application Server 7 Subsystems
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging for JBoss Application Server 7 Subsystems"
To view the document, visit: http://community.jboss.org/docs/DOC-17334
--------------------------------------------------------------
h3. *General Rules:*
* All exceptions and messages require a translation method in the @MessageBundle.
* All info and higher messages being logged require a translation method in the @MessageLogger.
* Messages in both the @MessageBundle and @MessageLogger should have an id***. Note though there are cases, specifically some methods in the @MessageBundle, that do not need id's. These typically include messages that are not being used in exceptions.
*** A list of id's can be found here http://community.jboss.org/docs/DOC-16810 http://community.jboss.org/wiki/LoggingIds
h3. *Examples:*
*
*
*Before:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw new StartException("Failed to create temp file provider");
}
log.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
*Methods added to DeploymentRepositoryMessages:*
/**
* Creates an exception indicating a failure to create a temp file provider.
*
* @return a {@link StartException} for the error.
*/
@Message(id = 14900, value = "Failed to create temp file provider")
StartException failedCreatingTempProvider();
*After:*
@Override
public void start(StartContext context) throws StartException {
try {
final JBossThreadFactory threadFactory = new JBossThreadFactory(new ThreadGroup("ServerDeploymentRepository-temp-threads"), Boolean.FALSE, null, "%G - %t", null, null, AccessController.getContext());
tempFileProvider = TempFileProvider.create("temp", Executors.newScheduledThreadPool(2, threadFactory));
} catch (IOException e) {
throw MESSAGES.failedCreatingTempProvider();
}
ROOT_LOGGER.debugf("%s started", ServerDeploymentRepository.class.getSimpleName());
}
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17334]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *
* |
|
| *10600 - 10699* | *Controller Client* |
|
| *10700 - 10799* | *Deployment Repository* |
|
| *10900 - 10999* | *Deployment Scanner* |
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* |
|
| *11200 - 11299* | *JAXRS* |
|
| *11300 - 11399* | *JMX* |
|
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* | I |
| *14400 - 14499* | *AppClient* | C |
| *14500 - 14599* | *JDR* |
|
| *14600 - 14899* | *Controller* | W |
| *14900 - 14999* | *Deployment Repository* | I |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
*Status:*
C = Complete
I = In Progress
W = Waiting Merge
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *
* |
|
| *10600 - 10699* | *Controller Client* |
|
| *10700 - 10799* | *Deployment Repository* |
|
| *10900 - 10999* | *Deployment Scanner* |
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* |
|
| *11200 - 11299* | *JAXRS* |
|
| *11300 - 11399* | *JMX* |
|
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* | I |
| *14400 - 14499* | *AppClient* | C |
| *14500 - 14599* | *JDR* |
|
| *14600 - 14899* | *Controller* | W |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 2 months