[JBoss AS7 Development] - What's causing this exception: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
by Jason Milliron
Jason Milliron [http://community.jboss.org/people/jm1468] created the discussion
"What's causing this exception: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory"
To view the discussion, visit: http://community.jboss.org/message/634059#634059
--------------------------------------------------------------
Hello. I'm using the a very recent nightly release of JBoss 7 and can't get my webapp up with CXF webservices. Does anyone know how I can stop this exception from happening or why it is being thrown?
Caused by: javax.xml.ws.WebServiceException: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:350)
at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:88)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:239)
at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:509)
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:116)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:109)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:132)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
... 5 more
Caused by: org.jboss.wsf.spi.WSFException: Failed to provide SPI:class org.jboss.wsf.spi.management.ServerConfigFactory
at org.jboss.ws.common.spi.DefaultSPIProvider.getSPI(DefaultSPIProvider.java:102)
at org.jboss.wsf.spi.SPIProvider.getSPI(SPIProvider.java:41)
at org.jboss.wsf.stack.cxf.transport.SoapTransportFactoryExt.getServerConfig(SoapTransportFactoryExt.java:102)
at org.jboss.wsf.stack.cxf.transport.SoapTransportFactoryExt.createEndpointInfo(SoapTransportFactoryExt.java:62)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpointInfo(AbstractWSDLBasedEndpointFactory.java:282)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:147)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:157)
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:202)
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:433)
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:322)
... 13 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634059#634059]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss Web Development] - expected number got Binary
by leonardo ginting
leonardo ginting [http://community.jboss.org/people/onesleo] created the discussion
"expected number got Binary"
To view the discussion, visit: http://community.jboss.org/message/634541#634541
--------------------------------------------------------------
hi guys i had an issue about expected number got binary does anybody knows what i should to do to solve this problem
this is the stack trace
1. java.sql.BatchUpdateException: ORA-00932: inconsistent datatypes: expected NUMBER got BINARY
2.
3. at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343)
4. at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10656)
5. at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
6. at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
7. at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
8. at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:266)
9. at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
10. at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
11. at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
12. at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
13. at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
14. at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137)
15. at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54)
16. at id.co.compnet.api.keu.ctl.DetailPendapatanJpaController.create(DetailPendapatanJpaController.java:42)
17. at id.co.compnet.PenerimaanDenda.PenerimaanDendaMBean.simpan(PenerimaanDendaMBean.java:391)
18. at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
and this is on my bean at line 391
for (DetailPendapatan detail : listPenerimaanDenda) {
System.out.println("MASUK SIMPAN DETAIL PENDAPATAN");
detail.setMataUang("IDR");
detail.setPenerimaanid(pendapatan);
detail.setBiayaid(biaya);
detail.setBiaya(new BigDecimal(getNilai()));
detail.setSubtotal(new BigDecimal(getSubtotal()));
detail.setVariabel(new BigInteger(getJumlah().toString()));
detailPendapatan = detail;
// System.out.println("PRINT DETAIL PENERIMAAN PENDAPTAN ID"+pendapatan +"BIAYA ID = "+biaya +" BIAYA = "+getNilai() +"SUBTOTAL ="+getSubtotal()+"VARIABEL = "+getJumlah());
LINE 391 => dcont.create(detailPendapatan);
System.out.print("DETAIL ID ="+detailPendapatan.getDetailpendapatanid());
}
ive printed all the value and i got all the value but why im still getting this error?
any solution guys?
thanks in advance
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634541#634541]
Start a new discussion in JBoss Web Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss AS7 Development] - use EJB3 issue:org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation
by duan xz
duan xz [http://community.jboss.org/people/duanxz] created the discussion
"use EJB3 issue:org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation"
To view the discussion, visit: http://community.jboss.org/message/634537#634537
--------------------------------------------------------------
Hi,
my ejb3 application run in jbossAS7,when i rollback transaction in app demo appear this error:
== server.log:==
1320214260246 [11-11-02 14:11:00.246] javax.ejb.ConcurrentAccessTimeoutException: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@1785fd3 - could not obtain lock within 5MINUTES
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:97)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.tx.StatefulBMTInterceptor.handleInvocation(StatefulBMTInterceptor.java:96)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:50)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.component.stateful.StatefulBMTInterceptor.processInvocation(StatefulBMTInterceptor.java:53)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:61)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
1320214260246 [11-11-02 14:11:00.246] at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
1320214260246 [11-11-02 14:11:00.246] at com.appeon.server.services.transactionservice.TransactionServiceBean3$$$view1.execute(Unknown Source)
==java code==
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.annotation.Resources;
import javax.ejb.CreateException;
import javax.ejb.Local;
import javax.ejb.PostActivate;
import javax.ejb.PrePassivate;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.ejb.Stateful;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;
import javax.transaction.SystemException;
import javax.transaction.UserTransaction;
import ASInterface.TransactionService;
@SuppressWarnings("serial")
@Stateful
@Local ({TransactionServiceBean3.class})
@TransactionManagement(TransactionManagementType.BEAN)
public class TransactionServiceBean3 extends AbstractTransactionService
implements SessionBean, TransactionService{
//~ Instance fields --------------------------------------------------------
/**
* DOCUMENT ME!
*/
@Resource
private SessionContext ctx;
//~ Methods ----------------------------------------------------------------
@PostActivate
public void ejbActivate()
{
System.out.println("1234567890::ejbActivate()");
}
public void ejbRemove()
{
System.out.println("1234567890::ejbRemove()");
}
@PreDestroy
public void remove(){
System.out.println("1234567890::remove()");
}
@PrePassivate
public void ejbPassivate()
{
}
@Resource
public void setSessionContext(SessionContext ctx)
{
System.out.println("duanxz nihao setSessionContext()");
this.ctx = ctx;
}
public void begin()
{
try
{
UserTransaction ut = (UserTransaction) ctx.getUserTransaction();
ut.setTransactionTimeout(18000);
ut.begin();
}
catch(IllegalStateException e)
{
Log.printStackTrace(e);
}
catch(SystemException e)
{
Log.printStackTrace(e);
}
catch(Throwable t)
{
Log.printStackTrace(t);
}
}
public void ejbCreate() throws CreateException
{
System.out.println("1234567890::ejbCreate()");
}
public void create() throws CreateException{
System.out.println("test 1234567890::create()");
}
public ReturnObject commitTransaction(int type)
{
try
{
System.out.println("TransactionServiceBean3.java 162");
UserTransaction tx = (UserTransaction) ctx.getUserTransaction();
tx.commit();
return new ReturnObject();
}
catch(Throwable t)
{
System.out.println("TransactionServiceBean3.java Error174:"+t.getMessage());
Log.printStackTrace(t);
return new ReturnObject(Globals.ERROR_CODE,
"Failed to commit transaction due to :\n" + t.toString());
}
}
public ReturnObject rollbackTransaction(int type)
{
System.out.println("TransactionServiceBean3.java 196");
try
{
UserTransaction tx = (UserTransaction) ctx.getUserTransaction();
tx.rollback();
return new ReturnObject();
}
catch(Throwable t)
{
System.out.println("TransactionServiceBean3.java Error213:"+t.getMessage());
Log.printStackTrace(t);
return new ReturnObject(Globals.ERROR_CODE,
"Failed to rollback transaction due to:\n" + t.toString());
}
}
}
Any help with this will be greatly appreciated.
Regards,
duanxz
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/634537#634537]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months
[JBoss AS7 Development] - Logging Id's
by Mike Clark
Mike Clark [http://community.jboss.org/people/miclark] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
These are ranges used for JBoss AS logging ids.
|| *Range* || *Subsystem
* || *Completed
* ||
| *10100 - 10199* | *Transaction* | Y |
| *10200 - 10399
* | *Clustering**
* | Y |
| *10400 - 10499* | *Connector**
* | Y |
| *10500 - 10599* | *Controller**
* |
|
| *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* | Y |
| *11500 - 11599* | *Logging* | Y |
| *11600 - 11699* | *Messaging* | Y |
| *11700 - 11799* | *mod_cluster* | Y |
| *11800 - 11899* | *Naming* | Y |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | Y |
| *12000 - 12099* | *Process Controller* | Y |
| *12100 - 12199* | *Protocol* | Y |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* |
|
| *14400 - 14499* | *AppClient* | |
| *14500 - 14599* | *JDR* |
|
--------------------------------------------------------------
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...]
12 years, 6 months
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Format of a Detyped Operation Request"
To view the document, visit: http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
See http://community.jboss.org/docs/DOC-16354 this page for a discussion of the format of the response.
See http://community.jboss.org/docs/DOC-16317 this page for a more in depth example of using the native management API.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = op.get("address");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the outermost elements appear in the request is not relevant. The required elements are:
* operation -- String -- The name of the operation being invoked.
* address -- the address of the managed resource against which the request should be executed. If not set, the address is the root resource. The address is an +ordered+ list of key-value pairs describing where the resource resides in the overall management resource tree. Management resources are organized in a tree, so the order in which elements in the address occur is important.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for operation, address and operation-headers.
h3. Operation Headers
Besides the special operation and address values discussed above, operation requests can also include special "header" values that help control how the operation executes. These headers are created under the special reserved word operation-headers:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = op.get("address");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
op.get("operation-headers", "rollback-on-runtime-failure").set(false);
System.out.println(op);
This produces:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"operation-headers" => {
"rollback-on-runtime-failure => false
}
}
The following operation headers are supported:
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether an operation that successfully updates the persistent configuration model should be reverted if it fails to apply to the runtime. Operations that affect the persistent configuration are applied in two stages -- first to the configuration model and then to the actual running services. If there is an error applying to the configuration model the operation will be aborted with no configuration change and no change to running services will be attempted. However, operations are allowed to changed the configuration model even if there is a failure to apply the change to the running services -- if and only if this rollback-on-runtime-failure header is set to false. So, this header only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
* rollout-plan -- only relevant to requests made to a Domain Controller or Host Controller. See "Operations with a Rollout Plan" for details.
* allow-resource-service-restart -- boolean, optional, defaults to false. Whether an operation that requires restarting some runtime services in order to take effect should do so. See discussion of resource-services in the "Applying Updates to Runtime Services" section of the http://community.jboss.org/docs/DOC-16317 Detyped Description of the AS 7 Management Model wiki for further details.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as an atomic unit*. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
+* See the discussion below of the rollback-on-runtime-failure operation header for how the atomicity requirement can be relaxed.+
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"operation-headers" => {
"rollback-on-runtime-failure => false
}
}
The "composite" operation takes a single parameter:
* steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps. Note that the rollback-on-runtime-failure and rollout-plan operation headers are not supported for the individual steps in a composite operation.
The rollback-on-runtime-failure operation header discussed above has a particular meaning when applied to a composite operation, controlling whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed.
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"operation-headers" => {
"rollout-plan" => {
"in-series" => [
{
"concurrent-groups" => {
"groupA" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupB" => undefined
}
},
{
"server-group" => {
"groupC" => {
"rolling-to-servers" => false,
"max-failed-servers" => 1
}
}
},
{
"concurrent-groups" => {
"groupD" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupE" => undefined
}
}
],
"rollback-across-groups" => true
}
}
}
As you can see, the rollout plan is another structure in the operation-headers section. The root node of the structure allows two children:
* in-series -- a list -- A list of steps that are to be performed in series, with each step reaching completion before the next step is executed. Each step involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
* rollback-across-groups -- boolean -- indicates whether the need to rollback the operation on all the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures:
* concurrent-groups -- a map of server group names to policies controlling how the operation should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
* server-group -- a single key/value mapping of a server group name to a policy controlling how the operation should be applied to that server group. See below for details on the policy configuration. +(Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)+
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
* rolling-to-servers -- boolean -- If true, the operation will be applied to each server in the group in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
* max-failed-servers -- int -- Maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
* max-failure-percentage -- int between 0 and 100 -- Maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
1. Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
2. Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
3. Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.
h3. Default Rollout Plan
All operations that impact multiple servers will be executed with a rollout plan. However, actually specifying the rollout plan in the operation request is not required. If no rollout-plan is specified, a default plan will be generated. The plan will have the following characteristics:
* There will only be a single high level phase. All server groups affected by the operation will have the operation applied concurrently.
* Within each server group, the operation will be applied to all servers concurrently.
* Failure on any server in a server group will cause rollback across the group.
* Failure of any server group will result in rollback of all other server groups.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 6 months