[JBoss ESB Development] - Re: Database already closed - jbpm persistence error on shutdown
by Kevin Conner
Kevin Conner [http://community.jboss.org/people/kconner] created the discussion
"Re: Database already closed - jbpm persistence error on shutdown"
To view the discussion, visit: http://community.jboss.org/message/595011#595011
--------------------------------------------------------------
There is nothing in that log that can help and, to be honest, it doesn't look like there is any ESB involvement at all.
* Check your datasource (i.e. *disable* shutdown hook on h2)
* Check your dependencies (i.e. make sure all deployments close *before* the database - you do have an mbean controlling it, right?)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/595011#595011]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
- 2
- 1
[JBoss ESB Development] - Re: Database already closed - jbpm persistence error on shutdown
by Arun Prasath siva thanu pillai
Arun Prasath siva thanu pillai [http://community.jboss.org/people/arunsprasath] created the discussion
"Re: Database already closed - jbpm persistence error on shutdown"
To view the discussion, visit: http://community.jboss.org/message/594967#594967
--------------------------------------------------------------
Hi,
I am also getting similar kind of error when I execute some sample application in jBPM5.
Please find the attached log along with mail and let me know your suggestion on the same.
Thanks,
Arun
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/594967#594967]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
- 1
- 0
[jBPM Development] - Newer for jpbm
by shiva raaj
shiva raaj [http://community.jboss.org/people/stsivarajjboss] created the discussion
"Newer for jpbm"
To view the discussion, visit: http://community.jboss.org/message/589987#589987
--------------------------------------------------------------
Hi everyone,
I am fresher for jBPM and so, how to learn jBPM and how to work.. Any can help me?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/589987#589987]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
- 2
- 1
[JBoss AS7 Development] - Re: Thoughts on filesystem action driven hot deployment
by Dimitris Andreadis
Dimitris Andreadis [http://community.jboss.org/people/dimitris] created the discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit: http://community.jboss.org/message/594138#594138
--------------------------------------------------------------
Is it just me that thinks you shouldn't need a marker file to initiate a deployment? A good design minimises the possibility of people screwing up by mistake.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/594138#594138]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
- 8
- 18
[JBoss AS7 Development] - Adding an Operation Handler for an AS 7 Subsystem
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Adding an Operation Handler for an AS 7 Subsystem"
To view the document, visit: http://community.jboss.org/docs/DOC-16655
--------------------------------------------------------------
This article is a quick description of the steps needed to add a new handler to an AS7 subsystem for handling a management operation.
This is as of the AS 7.0.0.Beta1 release. Developers are encouraged to look at the latest code as a better source for understanding the process. Looking at the handlers in the org.jboss.as.web package in the AS 7 source tree's web/ module is a good approach.
h3. Handling the Operation
1) The handler must implement the org.jboss.as.controller.OperationHandler interface or one of its subinterfaces.
2) Handlers that need to read or write the persistent management model (i.e. ones that don't solely deal with their subsystem's runtime services) must implement one of the following marker interfaces:
* ModelQueryOperationHandler -- for handlers that only read the persistent management model
* ModelAddOperationHandler -- for handlers that add a new +addressable resource+ to the model. (Inserting an attribute value for an existing resource is different.) Typically all handlers that implement this interface would be for an operation named "add".
* ModelRemoveOperationHandler -- for handlers that remove a +addressable resource+ from the model+.+ (Removing an attribute value for an existing resource to is different.) Typically all handlers that implement this interface would be for an operation named "remove".
* ModelUpdateOperationHandler -- for handlers that update existing resources in the persistent management model.
(Note: these marker interfaces may be replaced with a diferent mechanism for providing this information before AS 7.0.0.CR1)
3) Handlers are encouraged to perform some validation on the parameters contained in the passed in operation ModelNode. See the org.jboss.as.controller.operations.validation package for some general purpose helpers. If any parameter is invalid, the handler should throw OperationFailedException. OFE is the preferred exception for pretty much any failure condition.
4) If the handler needs to read or write the persistent management model, they can get a reference to the portion of the model indicated by the operation's address by calling context.getSubModel() on the passed in OperationContext.
5) If the operation doesn't throw an exception but the effect of the operation can be reversed via another operation, the operation should create a ModelNode that represents that "compensating operation" (E.g. an operation that sets an attribute to a new value would create a ModelNode that represents an operation to set the attribute back to the old value.) Pass this compensating operation out by calling
return new BasicOperationResult(compensatingOperation)
If there is no valid compensating operation (e.g. for a read-only operation) then
return new BasicOperationResult();
6) Handlers that seek to alter the runtime state are encouraged to do so asynchronously (i.e. after the call to OperationHandler.execute() returns . This is done by calling context.getRuntimeContext() on the passed in OperationContext.
* If that method returns null, the controller that called the handler has determined that it's currently inappropriate to execute runtime operations. The handler should not attempt to alter runtime state.
* Otherwise, the handler should create an object that implements the org.jboss.as.controller.RuntimeTask interface. This typical idiom is to create an anonymous inner class inside the OperationHandler.execute() method. This RuntimeTask should be passed to the calling context via a call to context.getRuntimeContext().setRuntimeTask(theTask)
The ModelController that called OperationHandler.execute() will ensure that either the runtime task is run or the changes made by the handler to the model are discarded.
The RuntimeTask *must* ensure that one (and only one) of the following methods is invoked on the passed in RuntimeHandler:
* handleResultComplete() -- if the runtime task is able to perform its changes successfully
* handleResultFailed(ModelNode failureDescription) -- if some problem occurs. The failureDescription should describe the problem.
The RuntimeTask need not invoke the ResultHandler directly. A common idiom is to install or remove an MSC Service in the RuntimeTask and to add a listener that invokes the RuntimeHandler when the service is started, stopped or fails. See ResultHandler.ServiceStartListener and ResultHandler.ServiceRemoveListener for ready-to-use listener implementations.
When the RuntimeTask executes, it is provided a RuntimeTaskContext from which it can get access to an MSC ServiceTarget and ServiceRegistry.
7) All handlers *must* do one (and only one) of the following in the execute method:
* Throw an exception (preferably OperationFailedException)
* On the passed in ResultHandler, invoke resultHandler.handleResultComplete()
* Register a RuntimeTask as described in 6) above.
8) Handlers must be thread safe. The handler can assume that any object passed in is thread safe (including the model made available via OperationContext.getSubModel()).
h3. Describing the Operation
All operations except "write-attribute" handlers (see below) must have a description that management API callers can access. The description is registered with the core management system along with the OperationHandler (see "Registering the Operation" below). The description must come from an implementation of the org.jboss.as.controller.descriptions.DescriptionProvider interface.
It is recommended that the handler implement the org.jboss.as.controller.descriptions.DescriptionProvider interface. When the OperationHandler implementation is registered, a DescriptionProvider impl must be registered with it, and having the same class implement both interfaces works well.
See http://community.jboss.org/docs/DOC-16317 http://community.jboss.org/docs/DOC-16317 for details on what the DescriptionProvider should return.
All free-form text output from a DescriptionProvider must be externalized into a ResourceBundle.
It is strongly encouraged that DescriptionProvider implementations have minimal code, and instead invoke a static method in a separate utility class. A typical idiom is to call that utility class XYZSubsystemDescriptions. The goal here is to improve boot time performance by not loading all the often-verbose code needed to generate description when the DescriptionProvider implemenation is loaded. Instead the code is loaded when the DescriptionProvider is invoked, which in many cases (e.g. embedded testing) will never occur.
h3. Handlers for the "write-attribute" Operation
The system includes a special operation called "write-attribute". This operation exists for every resource and takes two single parameters:
* name -- the name of the attribute that is being written
* value -- the new value of the attribute
This operation is logically equivalent to a JMX setAttribute call.
Calls to "write-attribute" will only be accepted for attributes that have had an OperationHandler registered (see below). The handler must know how to access the "name" and "value" parameters.
There is no need to write a DescriptionProvider to associate with the OperationHandler for a "write-attribute" operation.
h3. Registering the Operation
Your OperationHandler will only be invoked if the core management system knows about it. This is done by registering the handler as part of the subsystem's implementation of the org.jboss.as.controller.Extension interface, in the implementation of the Extension.initialize(ExtensionContext context) method.
Assume that the resource to which your operation applies had been registered as follows:
public void initialize(ExtensionContext context) {
final SubsystemRegistration subsystem = context.registerSubsystem(SUBSYSTEM_NAME);
final ModelNodeRegistration resource = subsystem.registerSubsystemModel(getTheRootResourceDescription());
If your OperationHandler is a handler for the "write-attribute" operation, e.g. for the "foo" attribute, it would generally be registered as follows:
resource.registerReadWriteAttribute("foo", null, handler, AttributeAccess.Storage.CONFIGURATION);
The second parameter is usually null. It could be an OperationHandler that is able to handle the "read-attribute" operation for the "foo" attribute. If null, a default handler is used that reads the current attribute value from the persistent configuration model.
The final parameter is either AttributeAccess.Storage.CONFIGURATION or AttributeAccess.Storage.RUNTIME. This indicates where the attribute value is stored. CONFIGURATION means it is stored in the persistent configuration; RUNTIME means it is stored in runtime memory only and the value will be lost on server restart.
For all other operations, the OperationHandler is registered as follows:
resource.registerOperationHandler("my-operation-name", handler, descriptionProvider);
where "my-operation-name" is the name of the operation the end user would invoke to trigger your handler.
A common idiom is to have the same class implement OperationHandler and DescriptionProvider, to make that class a singleton, and to declare the operation name as a constant on the handler class:
resource.registerOperationHandler(MyHandler.OPERATION_NAME, MyHandler.INSTANCE, MyHandler.INSTANCE);
There are some overloaded variants of ModelNodeRegistration.registerOperationHandler() that may be useful in some unusual situations. See the javadoc.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16655]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
- 1
- 0
[JBoss AS7 Development] - Detyped Description of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Detyped Description of the AS 7 Management Model"
To view the document, visit: http://community.jboss.org/docs/DOC-16317
--------------------------------------------------------------
AS 7's management API will naturally include the ability for clients to query the management system to discover meta-information about the management model; i.e. what resources are available and what attributes and operations they expose. These details will be returned in a detyped form, either using the https://github.com/jbossas/jboss-dmr jboss-dmr library or JSON. (A JMX interface based on open mbeans will also be provided; most concepts in this article map naturally to JMX.) The purpose of this article is to describe the detyped representation of the API.
Readers are encouraged to look at the example detyped descriptions of parts of the management API at the bottom before reading the details.
Before getting into the details of the meta-information, first a couple quick examples on how to access it.
h5. Reading Management Model Descriptions via the raw Management API
The client must have maven artifact org.jboss.as:jboss-as-controller-client and its dependencies on the classpath.
1) Create a management client that can connect to your target process's native management socket (which can be an individual standalone mode server, or, in a domain mode environment, the Domain Controller or any Host Controller:
ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("localhost"), 9999);
The address and port are what is configured in the target process' <management-apis><native-api.../> element.
2) Create an operation request object using the org.jboss.dmr.ModelNode class:
ModelNode op = new ModelNode();
op.get("operation").set("read-resource-description");
op.get("recursive").set(true);
op.get("operations").set(true);
ModelNode address = op.get("address");
address.add("subsystem", "web");
address.add("connector", "http");
See http://community.jboss.org/docs/DOC-16336 http://community.jboss.org/docs/DOC-16336 for basic background on the format of an operation request. The key thing here is we are executing the "read-resource-description" operation. That operation can be targetted at any address in the management model; here we are targetting it at the resource for the web subsystem's http connector.
The request includes two optional parameters:
* recursive -- true means you want the description of child resources under this resource. Default is false
* operations -- true means you want the description of operations exposed by the resource to be included. Default is false.
3) Execute the operation and manipulate the result:
ModelNode returnVal = client.execute(op);
System.out.println(returnVal.get("result").toString());
See http://community.jboss.org/docs/DOC-16354 http://community.jboss.org/docs/DOC-16354 for general details on the structure of the "returnVal" ModelNode.
h5. Reading Management Model Descriptions via the CLI
See http://community.jboss.org/docs/DOC-16581 http://community.jboss.org/docs/DOC-16581 for basics on using the CLI.
Once you've launched the CLI the syntax for the command shown above would be:
[localhost:9999 /] /subsystem=web/connector=http:read-resource-description(recursive=true,operations=true)
h3.
h3. Description of addressable portions of the management model
All portions of the management model exposed by AS 7 are addressable via an ordered list of key/value pairs. For each addressable portion of the model, the following descriptive information will be available:
* description -- String -- text description of this portion of the model
* head-comment-allowed -- boolean -- indicates whether this portion of the model can store an XML comment that would be written in the persistent form of the model (e.g. domain.xml) before the start of the XML element that represents this portion of the model. This item is optional, and if not present defaults to true.
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates whether a comment just before the close of the XML element is supported. A tail comment can only be supported if the element has child elements, in which case a comment can be inserted between the final child element and the element's closing tag. This item is optional, and if not present defaults to true.
* attributes -- Map of String (the attribute name) to complex structure -- the configuration attributes available in this portion of the model. See below for the representation of each attribute.
* operations -- Map of String (the operation name) to complex structure -- the operations that can be targetted at this address. See below for the representation of each operation.
* children -- Map of String (the type of child) to complex structure -- the relationship of this portion of the model to other addressable portions of the model. See below for the representation of each child relationship.
{
"description => "A managable resource",
"tail-comment-allowed" => false,
"attributes" => {
"foo" => {
.... details of attribute foo
}
},
"operations" => {
"start" => {
.... details of the start operation
}
},
"children" => {
"bar" => {
.... details of the relationship with children of type "bar"
}
}
}
h4. Description of an Attribute
An attribute is a portion of the management model that is not directly addressable. Instead, it is conceptually a property of an addressable part of the model. For each attribute portion of the model, the following descriptive information will be available:
* description -- String -- text description of the attribute
* type -- org.jboss.dmr.ModelType -- the type of the attribute value. One of the enum values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT, PROPERTY, STRING. Most of these are self-explanatory. An OBJECT will be represented in the detyped model as a map of string keys to values of some other legal type, conceptually similar to a javax.management.openmbean.CompositeData. A PROPERTY is a single key/value pair, where the key is a string, and the value is of some other legal type.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT. If type is LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, PROPERTY, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
* required -- boolean -- true if the attribute will always exist in a representation of its portion of the model; false if it may not (implying a null value.) If not present, true is the default.
* head-comment-allowed -- boolean -- indicates whether the model can store an XML comment that would be written in the persistent form of the model (e.g. domain.xml) before the start of the XML element that represents this attribute. This item is optional, and if not present defaults to *false*. (This is a different default from is used for an addressable portion of the model, since model attributes often map to XML attributes, which don't allow comments.)
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates whether a comment just before the close of the XML element is supported. A tail comment can only be supported if the element has child elements, in which case a comment can be inserted between the final child element and the element's closing tag. This item is optional, and if not present defaults to *false*. (This is a different default from is used for an addressable portion of the model, since model attributes often map to XML attributes, which don't allow comments.)
* arbitrary key/value pairs that further describe the attribute value, e.g. "max" => 2. See "Arbitrary Descriptors" below.
"foo" => {
"description" => "The foo",
"type" => INT,
"max" => 2
}
"bar" => {
"description" => "The bar",
"type" => OBJECT,
"value-type" => {
"size" => INT,
"color" => STRING
}
}
h3. Description of an Operation
An addressable portion of the model may have operations associated with it. The description of an operation will include the following information:
* operation-name -- String -- the name of the operation
* description -- String -- text description of the operation
* request-properties -- Map of String to complex structure -- description of the parameters of the operation. Keys are the names of the parameters, values are descriptions of the parameter value types. See below for details on the description of parameter value types.
* reply-properties -- complex structure, or empty -- description of the return value of the operation, with an empty node meaning void.
h4. Description of an Operation Parameter or Return value
* description -- String -- text description of the parameter or return value
* type -- org.jboss.dmr.ModelType -- the type of the parameter or return value. One of the enum values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT, PROPERTY, STRING.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT. If type is LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, PROPERTY, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
* required -- boolean -- Only relevant to parameters. true if the parameter must be present in the request object used to invoke the operation; false if it can omitted. If not present, true is the default.
* nillable -- boolean -- true if null is a valid value. If not present, false is the default.
* arbitrary key/value pairs that further describe the attribute value, e.g. "max" =>2. See "Arbitrary Descriptors" below.
{
"operation-name" => "incrementFoo",
"description" => "Increase the value of the 'foo' attribute by the given amount",
"request-properties" => {
"increment" => {
"type" => INT,
"description" => "The amount to increment",
"required" => true
}},
"reply-properties" => {
"type" => INT,
"description" => "The new value",
}
}
{
"operation-name" => "start",
"description" => "Starts the thing",
"request-properties" => {},
"reply-properties" => {}
}
h2. Arbitrary Descriptors
The description of an attribute, operation parameter or operation return value type can include arbitrary key/value pairs that provide extra information. Whether a particular key/value pair is present depends on the context, e.g. a pair with key "max" would probably only occur as part of the description of some numeric type.
Following are standard keys and their expected value type. If descriptor authors want to add an arbitrary key/value pair to some descriptor and the semantic matches the meaning of one of the following items, the standard key/value type should be used.
* min -- int -- the minimum value of some numeric type. The absence of this item implies there is no minimum value.
* max -- int -- the maximum value of some numeric type. The absence of this item implies there is no maximum value.
* min-length -- int -- the minimum length of some string, list or byte[] type. The absence of this item implies a minimum length of zero.
* max-length -- int -- the maximum length of some string, list or byte[]. The absence of this item implies there is no maximum value.
* nillable -- boolean -- whether null is a legal value. The absence of this item implies false; i.e. null is not a legal value.
* allowed -- List -- a list of legal values. The type of the elements in the list should match the type of the attribute.
* unit - The unit of the value - e.g. ns, ms, s, m, h, KB, MB, TB. Maybe similar allowed values like http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/core/doma... MeasurmentUnits.
h2. Description of Parent/Child Relationships
The address used to target an addressable portions of the model must be an ordered list of key value pairs. The effect of this requirement is the addressable portions of the model naturally form a tree structure, with parent nodes in the tree defining what the valid keys are and the children defining what the valid values are. The parent node also defines the cardinality of the relationship. The description of the parent node includes a children element that describes these relationships:
{
....
"children" => {
"connector" => {
.... description of the relationship with children of type "connector"
},
"virtual-host" => {
.... description of the relationship with children of type "virtual-host"
}
}
The description of each relationship will include the following elements:
* description -- String -- text description of the relationship
* min-occurs -- int, either 0 or 1 -- Minimum number of children of this type that must exist in a valid model. If not present, the default value is 0.
* max-occurs -- int -- Maximum number of children of this type that may exist in a valid model. If not present, the default value is Integer.MAX_VALUE, i.e. there is no limit.
* allowed -- List of strings -- legal values for children names. If not present, there is no restriction on children names.
* model-description -- either "undefined" or a complex structure -- This is the full description of the child resource (its text description, attributes, operations, children) as detailed above. This may also be "undefined", i.e. a null value, if the query that asked for the parent node's description did not include the "recursive" param set to true.
Example with if the recursive flag was set to true:
{
"description" => "The connectors used to handle client connections",
"min-occurs" > 1,
"model-description" => {
"description" => "Handles client connections",
"attributes => {
... details of children as documented above
},
"operations" => {
.... details of operations as documented above
},
"children" => {
.... details of the children's children
}
}
}
If the recursive flag was false:
{
"description" => "The connectors used to handle client connections",
"min-occurs" > 1,
"model-description" => undefined
}
h2. Example Representation of a Portion of the Domain Controller API
{
"description" => "The root node of the domain-level management model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the configuration XML document, where keys are namespace prefixes and values are schema URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in the configuration XML document, where keys are schema URIs and values are locations where the schema can be found.",
"required" => false
}
},
"operations" => "TODO",
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths. The paths may or may not be fully specified (i.e. include the actual paths.)",
"model-description" => {
"description" => "A named filesystem path, but without a requirement to specify the actual path. If no actual path is specified, acts as a placeholder in the model (e.g. at the domain level) until a fully specified path definition is applied at a lower level (e.g. at the host level, where available addresses are known.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot be one of the standard fixed paths provided by the system: <ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li></ul> Note that the system provides other standard paths that can be overridden by declaring them in the configuration file. See the 'relative-to' attribute documentation for a complete list of standard paths.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"required" => false,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path' child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path' child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the 'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the 'path' attribute",
"required" => true,
"min-length" => 1,
"nillable" => true
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the 'relative-to' attribute",
"request-properties" => {"relative-to" => {
"type" => STRING,
"description" => "The new value of the 'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"profile" => {
"description" => "A list of profiles available for use in the domain",
"min-occurs" => 1,
"model-description" => {
"description" => "A named set of subsystem configurations.",
"attributes" => {"name" => {
"type" => STRING,
"description" => "The name of the profile",
"required" => true,
"min-length" => 1
}},
"operations" => {},
"children" => {
"subsystem" => {
"description" => "The subsystems that make up the profile.",
"min-occurs" => 1,
"model-description" => {}
},
"include" => {"model-description" => {
"description" => "Specifies that a contents of a named profile are to be included in the profile whose definition includes this item.",
"head-comment-allowed" => true,
"tail-comment-allowed" => false,
"attributes" => {"profile" => {
"type" => LIST,
"description" => "The name of the included profile",
"required" => true,
"value-type" => STRING
}},
"operations" => "TODO"
}}
}
}
},
"interface" => {
"description" => "A list of named network interfaces available for use in the domain. The interfaces may or may not be fully specified (i.e. include criteria on how to determine their IP address.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"socket-binding-group" => {
"description" => "A list of socket binding groups available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"system-property" => {
"description" => "A list of system properties to set on all servers in the domain.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"deployment" => {
"description" => "A list of deployments available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"server-group" => {
"description" => "A list of server groups available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"host" => {
"description" => "Host controllers currently running in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
}
}
}
h2. Example Representation of a Portion of the Host Controller API
{
"description" => "The root node of the host-level management model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the configuration XML document, where keys are namespace prefixes and values are schema URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in the configuration XML document, where keys are schema URIs and values are locations where the schema can be found.",
"required" => false
},
"management" => {
"description" => "Configuration of the host's management system.",
"type" => OBJECT,
"value-type" => {
"interface" => {
"type" => STRING,
"description" => "Interface on which the host's socket for intra-domain management communication should be opened.",
"required" => false
},
"port" => {
"type" => STRING,
"description" => "Port on which the host's socket for intra-domain management communication should be opened.",
"required" => false
}
},
"required" => true,
"head-comment-allowed" => true
},
"domain-controller" => {
"description" => "Configuration of how the host should interact with the Domain Controller",
"type" => OBJECT,
"value-type" => "TODO",
"required" => true,
"head-comment-allowed" => true,
"tail-comment-allowed" => true
}
},
"operations" => {
"start-server" => {
"operation-name" => "start-server",
"description" => "Start a server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
},
"restart-server" => {
"operation-name" => "restart-server",
"description" => "Restart a currently running server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
},
"stop-server" => {
"operation-name" => "stop-server",
"description" => "Stop a currently running server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
}
},
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths.",
"min-occurs" => 0,
"model-description" => {
"description" => "A named filesystem path, but without a requirement to specify the actual path. If no actual path is specified, acts as a placeholder in the model (e.g. at the domain level) until a fully specified path definition is applied at a lower level (e.g. at the host level, where available addresses are known.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot be one of the standard fixed paths provided by the system: <ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li></ul> Note that the system provides other standard paths that can be overridden by declaring them in the configuration file. See the 'relative-to' attribute documentation for a complete list of standard paths.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path' child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path' child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the 'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the 'path' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the 'relative-to' attribute",
"request-properties" => {"relative-to" => {
"type" => STRING,
"description" => "The new value of the 'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"system-property" => {
"description" => "A list of system properties to set on all servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"interface" => {
"description" => "A list of fully specified named network interfaces available for use on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"jvm" => {
"description" => "A list of Java Virtual Machine configurations that can be applied ot servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"server-config" => {
"description" => "Host-level configurations for the servers that can run on this host.",
"min-occurs" => 0
"model-description" => {}
},
"server" => {
"description" => "Servers currently running on the host",
"min-occurs" => 0
"model-description" => "TODO"
}
}
}
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16317]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
- 1
- 0
[JBoss AS7 Development] - Command Line Interface
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/aloubyansky] modified the document:
"Command Line Interface"
To view the document, visit: http://community.jboss.org/docs/DOC-16581
--------------------------------------------------------------
The AS7 Command Line Interface (CLI) is a command line management tool for the AS 7 domain or a standalone server. It allows a user to connect to the AS7 domain controller or a standalone server and execute management operations available through the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model. Depending on the operation system, the CLI is launched using jboss-admin.sh or jboss-admin.bat located in the AS7 bin directory.
h2. Features
The CLI features include:
* connect to the specific controller or server instance by specifying the host and the port;
* send operation requests (providing the managed component's address, attribute or operation name and parameters) following the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model;
* view the available managed components, their attributes and operations;
* tab-completion for commands and operation requests;
* history of the executed commands and operation requests.
h2. Commands
There are commands and operations. Commands don't trigger server management actions, they are performed locally and may affect only the command line session settings. Operations, on the other hand, are actually translated into the operation requests and sent for the execution to the server.
To see all the commands and their description, enter command +help+. Another way to list all the supported commands is to press the tab key at the command line prompt which will trigger the tab-completion for the commands.
h3. Connection
The first thing to do after the CLI has started is to connect to a managed AS7 instance. This is done using the command +connect+, e.g.
+connect+
which is equivalent to
+connect localhost:9999+
localhost:9999 is the default host and port combination for the AS7 model controller client. Both, the host and the port, are optional parameters and can be specified together or separately.
h3. Quit
To terminate the session type +quit+.
h2. Operation requests
The format for the operation requests is
[node-type=node-name (,node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]
e.g.
profile=production,subsystem=threads,bounded-queue-thread-pool=pool1:write-core-threads (count=0, per-cpu=20)
It's a lot of typing but tab-completion is supported for all the composing parts, i.e. node-types and node-names, operation names and parameter names. We are also looking into adding custom commands/aliases that would be less verbose for the user but would translate into the corresponding operation requests on the background.
Whitespaces between the separators in the operation request strings are not significant.
Operation requests might not always have the address part or the parameters. E.g.
+:read-resource+
which will list all the node types for the current node.
To syntactically disambiguate between the commands and operations, operations require one of the following prefixes:
* +:+ - to execute an operation against the current node, e.g.
+[subsystem=web] :read-resource(recursive="true")+
+
+
* +./+ - to execute an operation against a child node of the current node, e.g.
+[subsystem=web] ./connector=http:read-resource+
i.e. the full address of the operation will be +subsystem=web,connector=http+.
* +/+ - to execute an operation against the root node, e.g.
+[subsystem=web] /:read-resource+
or its child, e.g.
+[subsystem=web] /subsystem=logging:read-resource+
h3. How the tab-completion works
Suppose, the cursor is positioned at the beginning of an empty line. If you type in +'./'+ and press the tab key, you will get a list of all the available node types. After selecting the node type you want and adding '=', pressing the tab key again will result in a list of all the node names available for the chosen node type. If, after selecting the node name from the list, you want to continue with the node path then add ',' after the selected node name and press the tab key again. This will print all the available node types for the previously select node.
After you are done with the node path, adding ':' at the end of the node path and pressing the tab key will print all the available operation names for the selected node.
To see all the parameters of the operation, add '(' after the operation name and press the tab key. Choose the parameter you want and specify its value after '='. Tab-completion for parameter values is not supported (yet?). If you want to add more parameters, add ',' and press the tab key to see the rest of the available parameter names.
Finally, when all the parameters have been specified, add ')' and press enter.
In the node path you can use the following strings for navigations:
* .. - parent node, e.g.
+[/] ./subsystem=web/../subsystem=transactions+
is equivalent to
+[/] ./subsystem=transactions+
* +.type+ - the type of the current node, e.g.
+[/] ./subsystem=web/.type/transactions+
is equivalent to the same
+[/] ./subsystem=transactions+
h2. Current node path and navigation
The current node path is indicated in the command line prompt. The default value is '/', i.e. the root node. All the operation requests that don't contain the address part will be executed against the current node path.
h4. Change node command (cn or cd)
+cn+, or +cd+, command allows you to change the current node path, e.g.
+[host:port /] cd subsystem=web+
After that the command line prompt will change to
+[host:port /subsystem=web]+
and every operation entered w/o the node path will be executed against the node subsystem=web. If you do specify a node path for the operation, it will be considered relative to subsystem=web.
The node path might not necessarily end on a node name. It might be just
+[host:port /] cd subsystem+
+[host:port /subsystem]+
Then to execute an operation against the logging subsystem you would type in
+[host:port /subsystem] logging:read-resource+
To go back to the root node, type in
+[host:port /subsystem] cd /+
+[host:port /]+
You can also navigate to the parent node
+[++host:port /++subsystem=web,connector=http] cd ..+
+[++host:port /++subsystem=web]+
or the node type
+[++host:port /++subsystem=web] cd .type+
+[++host:port /++subsystem]+
h4. List contents command (ls)
+ls+ command will list the contents of a node path. The command has an optional node path argument. If the argument is specified, the command will print the contents of the node path specified in the argument. If the argument is not specified, the command will print the contents of the current node path (indicated in the prompt).
If the node path ends on a node type then the contents will be the child node names. If the node path ends on a node name then the contents will be the child node types.
If the contents of the node path is empty, nothing will be printed.
Example:
+[localhost:9999 /subsystem=web] ls+
+virtual-server connector+
+[localhost:9999 /subsystem=web] ls connector +
+http+
+[localhost:9999 /subsystem=web]+
h2. Special characters in node names
White ':' and '/' have special significance for in the format of the operation request, these characters aren't disallowed in node names.
If they are typed in though, the operation request parser will be confused and will probably result it an error. To workaround this issue you should quote the names with special characters, e.g.
+[localhost:9999 /subsystem=datasources] cd data-source="java:/H2DS"+
+[localhost:9999 /subsystem=datasources/data-source=java:/H2DS]+
The node name, actually, is also allowed to contain '"'. In case the node name has to be quoted and it also contains quotes in its content then the quotes that are a part of the node name content have to be escaped using, i.e. '\"'.
+[localhost:9999 /] cd nodetype="node:name/with\"quotes\""+
+[localhost:9999 /node:name/with"quotes"]
+
Note, that the tab-completion takes care of this automatically.
h3. Command history
Command (and operation request) history is enabled by default. The history is kept both: in-memory and in a file on the disk, i.e. it is preserved between the command line sessions. The history file name is .jboss-cli-history and is automatically created in the user's home directory. When the command line interface is launched this file is read and the in-memory history is initialized with its content.
While in the command line session, you can use the arrow keys to go back and forth in the history of commands and operations. To manipulate the history you can use +history+ command.
If executed w/o the argument, it will print all the recorded commands and operations (up to the configured maximum, which is by default 500) from the in-memory history.
+history+ supports three optional arguments:
* disable - will disable history expansion (but will not clear the previously recorded history);
* enabled - will re-enable history expansion (starting from the last recorded command before the history expansion was disabled);
* clear - will clear the in-memory history (but not the file one).
h2. Ideas for features and improvements
* custom aliases/commands for existing commands and operations (too avoid verbosity)
* command/operation output redirection, e.g. operation > file, operation < file
* report operation results nicer (success shorter, failure with more details)
* an easy way to get an operation description, e.g. 'help operation-name
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16581]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
- 1
- 0
[JBoss AS7 Development] - Command Line Interface
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/aloubyansky] modified the document:
"Command Line Interface"
To view the document, visit: http://community.jboss.org/docs/DOC-16581
--------------------------------------------------------------
The AS7 Command Line Interface (CLI) is a command line management tool for the AS 7 domain or a standalone server. It allows a user to connect to the AS7 domain controller or a standalone server and execute management operations available through the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model. Depending on the operation system, the CLI is launched using jboss-admin.sh or jboss-admin.bat located in the AS7 bin directory.
h2. Features
The CLI features include:
* connect to the specific controller or server instance by specifying the host and the port;
* send operation requests (providing the managed component's address, attribute or operation name and parameters) following the http://community.jboss.org/docs/DOC-16317 AS7 detyped management model;
* view the available managed components, their attributes and operations;
* tab-completion for commands and operation requests;
* history of the executed commands and operation requests.
h2. Commands
There are commands and operations. Commands don't trigger server management actions, they are performed locally and may affect only the command line session settings. Operations, on the other hand, are actually translated into the operation requests and sent for the execution to the server.
To see all the commands and their description, enter command +help+. Another way to list all the supported commands is to press the tab key at the command line prompt which will trigger the tab-completion for the commands.
h3. Connection
The first thing to do after the CLI has started is to connect to a managed AS7 instance. This is done using the command +connect+, e.g.
+connect+
which is equivalent to
+connect localhost:9999+
localhost:9999 is the default host and port combination for the AS7 model controller client. Both, the host and the port, are optional parameters and can be specified together or separately.
h3. Quit
To terminate the session type +quit+.
h2. Operation requests
The format for the operation requests is
[node-type=node-name (,node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]
e.g.
profile=production,subsystem=threads,bounded-queue-thread-pool=pool1:write-core-threads (count=0, per-cpu=20)
It's a lot of typing but tab-completion is supported for all the composing parts, i.e. node-types and node-names, operation names and parameter names. We are also looking into adding custom commands/aliases that would be less verbose for the user but would translate into the corresponding operation requests on the background.
Whitespaces between the separators in the operation request strings are not significant.
Operation requests might not always have the address part or the parameters. E.g.
+:read-resource+
which will list all the node types for the current node.
To syntactically disambiguate between the commands and operations, operations require one of the following prefixes:
* +:+ - to execute an operation against the current node, e.g.
+[subsystem=web] :read-resource(recursive="true")+
+
+
* +./+ - to execute an operation against a child node of the current node, e.g.
+[subsystem=web] ./connector=http:read-resource+
i.e. the full address of the operation will be +subsystem=web,connector=http+.
* +/+ - to execute an operation against the root node, e.g.
+[subsystem=web] /:read-resource+
or its child, e.g.
+[subsystem=web] /subsystem=logging:read-resource+
h3. How the tab-completion works
Suppose, the cursor is positioned at the beginning of an empty line. If you type in +'./'+ and press the tab key, you will get a list of all the available node types. After selecting the node type you want and adding '=', pressing the tab key again will result in a list of all the node names available for the chosen node type. If, after selecting the node name from the list, you want to continue with the node path then add ',' after the selected node name and press the tab key again. This will print all the available node types for the previously select node.
After you are done with the node path, adding ':' at the end of the node path and pressing the tab key will print all the available operation names for the selected node.
To see all the parameters of the operation, add '(' after the operation name and press the tab key. Choose the parameter you want and specify its value after '='. Tab-completion for parameter values is not supported (yet?). If you want to add more parameters, add ',' and press the tab key to see the rest of the available parameter names.
Finally, when all the parameters have been specified, add ')' and press enter.
In the node path you can use the following strings for navigations:
* .. - parent node, e.g.
+[/] ./subsystem=web/../subsystem=transactions+
is equivalent to
+[/] ./subsystem=transactions+
* +.type+ - the type of the current node, e.g.
+[/] ./subsystem=web/.type/transactions+
is equivalent to the same
+[/] ./subsystem=transactions+
h2. Current node path and navigation
The current node path is indicated in the command line prompt. The default value is '/', i.e. the root node. All the operation requests that don't contain the address part will be executed against the current node path.
h4. Change node command (cn or cd)
+cn+, or +cd+, command allows you to change the current node path, e.g.
+[host:port /] cd subsystem=web+
After that the command line prompt will change to
+[host:port /subsystem=web]+
and every operation entered w/o the node path will be executed against the node subsystem=web. If you do specify a node path for the operation, it will be considered relative to subsystem=web.
The node path might not necessarily end on a node name. It might be just
+[host:port /] cd subsystem+
+[host:port /subsystem]+
Then to execute an operation against the logging subsystem you would type in
+[host:port /subsystem] logging:read-resource+
To go back to the root node, type in
+[host:port /subsystem] cd /+
+[host:port /]+
You can also navigate to the parent node
+[++host:port /++subsystem=web,connector=http] cd ..+
+[++host:port /++subsystem=web]+
or the node type
+[++host:port /++subsystem=web] cd .type+
+[++host:port /++subsystem]+
h4. List contents command (ls)
+ls+ command will list the contents of a node path. The command has an optional node path argument. If the argument is specified, the command will print the contents of the node path specified in the argument. If the argument is not specified, the command will print the contents of the current node path (indicated in the prompt).
If the node path ends on a node type then the contents will be the child node names. If the node path ends on a node name then the contents will be the child node types.
If the contents of the node path is empty, nothing will be printed.
Example:
+[localhost:9999 /subsystem=web] ls+
+virtual-server connector+
+[localhost:9999 /subsystem=web] ls connector +
+http+
+[localhost:9999 /subsystem=web]+
h2. Special characters in node names
White ':' and '/' have special significance for in the format of the operation request, these characters aren't disallowed in node names.
If they are typed in though, the operation request parser will be confused and will probably result it an error. To workaround this issue you should quote the names with special characters, e.g.
+[localhost:9999 /subsystem=datasources] cd data-source="java:/H2DS"+
+[localhost:9999 /subsystem=datasources/data-source=java:/H2DS]+
The node name, actually, is also allowed to contain '"'. In case the node name has to be quoted and it also contains quotes in its content then the quotes that are a part of the node name content have to be escaped using, i.e. '\"'.
+[localhost:9999 /] cd nodetype="node:name/with\"quotes\""+
+[localhost:9999 /node:name/with"quotes"]
+
Note, that the tab-completion takes care of this automatically.
h2. Ideas for features and improvements
* custom aliases/commands for existing commands and operations (too avoid verbosity)
* command/operation output redirection, e.g. operation > file, operation < file
* report operation results nicer (success shorter, failure with more details)
* an easy way to get an operation description, e.g. 'help operation-name
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16581]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
- 1
- 0
[JBoss Web Services Development] - Jboss ws, auto decode soap message from utf.
by DimShust Shust
DimShust Shust [http://community.jboss.org/people/dimshust1985] created the discussion
"Jboss ws, auto decode soap message from utf."
To view the discussion, visit: http://community.jboss.org/message/594738#594738
--------------------------------------------------------------
I've done servlet and deployed it into jboss. Servlet is working as web service. All is working correctly. But, when my client send SOAP message on server. Jboss decodes this message from utf to ASCII. Another words, when message goes away from client, it's in utf-8, when it is coming in @webmethod it already in ASCII. SO, how i think, JBOSS automatic decodes this message.
So, i dont need it.. And i cant understand, how can i stop it.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/594738#594738]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
- 1
- 0
Re: [jboss-dev-forums] [JBoss AS7 Development] - JBoss AS7 User Guide
by xsa lefter
xsa lefter [http://community.jboss.org/people/xsalefter] commented on the document
"JBoss AS7 User Guide"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16068#comment-5775
--------------------------------------------------
Just download and try running it on vista, then got:
18:14:13,737 INFO [org.jboss.modules] (main) JBoss Modules version 1.0.0.Beta16
18:14:14,034 INFO [org.jboss.as.process.Host Controller.status] (main) Starting process 'Host Controller'
[Host Controller] 18:14:14,661 INFO [org.jboss.modules] (main) JBoss Modules version 1.0.0.Beta16
[Host Controller] 18:14:15,134 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.0.Beta7
[Host Controller] 18:14:15,714 INFO [org.jboss.as.domain.controller] (MSC service thread 1-4) Starting Domain Controller
[Host Controller] 18:14:16,539 ERROR [org.jboss.as.domain.controller] (MSC service thread 1-4) failed to start domain controller: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
[Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:120)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerService.loadLocalDomainModel(DomainControllerService.java:185)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerService.startMasterDomainController(DomainControllerService.java:137)
[Host Controller] at org.jboss.as.domain.controller.DomainControllerService.start(DomainControllerService.java:91)
[Host Controller] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) [:1.6.0_06]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) [:1.6.0_06]
[Host Controller] at java.lang.Thread.run(Thread.java:619) [:1.6.0_06]
[Host Controller] Caused by: javax.xml.stream.XMLStreamException: org.jboss.jca.common.api.validator.ValidateException: jndiName (xml attribure jndi-name) is required in org.jboss.jca.common.metadata.ds.DataSourceImpl
[Host Controller] at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$NewDataSourceSubsystemParser.readElement(DataSourcesExtension.java:449)
[Host Controller] at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$NewDataSourceSubsystemParser.readElement(DataSourcesExtension.java:170)
[Host Controller] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
[Host Controller] at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
[Host Controller] at org.jboss.as.controller.parsing.DomainXml.parseProfiles(DomainXml.java:516)
[Host Controller] at org.jboss.as.controller.parsing.DomainXml.readDomainElement(DomainXml.java:186)
[Host Controller] at org.jboss.as.controller.parsing.DomainXml.readElement(DomainXml.java:88)
[Host Controller] at org.jboss.as.controller.parsing.DomainXml.readElement(DomainXml.java:80)
[Host Controller] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
[Host Controller] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
[Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112)
[Host Controller] ... 7 more
[Host Controller] Caused by: org.jboss.jca.common.api.validator.ValidateException: jndiName (xml attribure jndi-name) is required in org.jboss.jca.common.metadata.ds.DataSourceImpl
[Host Controller] at org.jboss.jca.common.metadata.ds.DataSourceAbstractImpl.partialCommonValidation(DataSourceAbstractImpl.java:262)
[Host Controller] at org.jboss.jca.common.metadata.ds.DataSourceAbstractImpl.<init>(DataSourceAbstractImpl.java:142)
[Host Controller] at org.jboss.jca.common.metadata.ds.DataSourceImpl.<init>(DataSourceImpl.java:90)
[Host Controller] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSource(DsParser.java:375)
[Host Controller] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSources(DsParser.java:157)
[Host Controller] at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:112)
[Host Controller] at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$NewDataSourceSubsystemParser.readElement(DataSourcesExtension.java:437)
[Host Controller] ... 17 more
Any idea?
--------------------------------------------------
13 years, 10 months
- 1
- 0