[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. …
[View More]Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction). *ANSWER: we will allow it and design for it.*
2. For a few different cases, we will need to know which EntityManager was injected into a component. One such case is for XPC inheritance. For example, SFSB1 (with extended persistence context) gets injected into a web component and SFSB2 (with extended persistence context) gets injected into SFSB1. SFSB2 should inherit the XPC from SFSB1. Open question is how we want to maintain the bookkeeping for this. The JPA layer could expose a SPI like BeanToEntityManager{ List<EntityManager> getEntityManagers(); } that can be passed in on other SPI calls (basically depending on the EJB container to track injected EntityMangers via other magic). Another solution would be to track the mapping in the JPA layer (might be a pretty big map with a lot of weak references that need to be considerate of GC/undeploy concerns). Or perhaps there will some other solution that will appear for this. :)
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
- 1
- 0
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] 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 …
[View More]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.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("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("op").set("setCoreThreads");
ModelNode addr = opB.get("op-addr");
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);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements are:
* op -- String -- The name of the operation being invoked.
* op-addr -- the address of the managed resource against which the request should be executed.
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 op, op-addr and rollout-plan.
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:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
"rollout-plan" => "TODO"
}
+TODO -- flesh out the structure of the rollout plan!+
As you can see, the rollout plan is simply another structure at the same level as op, op-addr and the operation parameters.+
+
--------------------------------------------------------------
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...]
[View Less]
14 years, 2 months
- 1
- 0
Re: [jboss-dev-forums] [JBoss AS7 Development] - Detyped Representation of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] commented on the document
"Detyped Representation of the AS 7 Management Model"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16317#comment-5206
--------------------------------------------------
In the initial version of this article, the "type" and "value-type" handling isn't right.
First, I don't think we should use org.jboss.dmr.ModelType for any enumerated values, as the …
[View More]purpose is different. ModelType gives information to someone with a ref to a ModelNode to let them determine the structure of the node.
A small improvement would be to make type one of an enumerated list of values: BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, MAP (new), PROPERTY, STRING, or a complex structure detailing the fields and values of a non-simple-map kinds of dmr OBJECTs. The value-type is used with LIST, MAP, PROPERTY to describe the type list elements & map/property values, and is itself either on of the enumerated values or a complex structure.
This breaks down, of course, if value-type is itself LIST, MAP or PROPERTY.
These type descriptions will also break down for dynamic data; e.g. the reply-properties value for a generic operation like some generic "readAttribute" with param "attribute-name" => "foo". The description of the return value depends on the value of "attribute-name".
Similar issue exists with multi-step operations, where the structure of the return value incorporates multiple values, or with domain or host level operations, where the return value includes results from a dynamic set of hosts and servers.
--------------------------------------------------
[View Less]
14 years, 2 months
- 1
- 0
[JBoss AS7 Development] - Detyped Representation of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Detyped Representation 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 …
[View More]attributes and operations they expose. These details will be returned in a detyped form, either using the 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.
+TODO -- add initial section showing using the Java API to access the information described below.+
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.
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...]
[View Less]
14 years, 2 months
- 1
- 0
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. …
[View More]Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction). *ANSWER: we will allow it and design for it.*
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
[View Less]
14 years, 2 months
- 1
- 0
[JBoss AS7 Development] - Detyped Representation of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Detyped Representation 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 …
[View More]attributes and operations they expose. These details will be returned in a detyped form, either using the 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.
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.
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.
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.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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.)",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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,
"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,
"max-occurs" => 2147483647,
"model-description" => {
"description" => "A named set of subsystem configurations.",
"head-comment-allowed" => true,
"tail-comment-allowed" => true,
"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,
"max-occurs" => 2147483647,
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"socket-binding-group" => {
"description" => "A list of socket binding groups available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"system-property" => {
"description" => "A list of system properties to set on all servers in the domain.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"deployment" => {
"description" => "A list of deployments available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"server-group" => {
"description" => "A list of server groups available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"host" => {
"description" => "Host controllers currently running in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => {}
}
}
}
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,
"nillable" => false
}},
"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,
"nillable" => false
}},
"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,
"nillable" => false
}},
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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,
"nillable" => false
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"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" => false
}},
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"interface" => {
"description" => "A list of fully specified named network interfaces available for use on the host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"jvm" => {
"description" => "A list of Java Virtual Machine configurations that can be applied ot servers on the host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"server-config" => {
"description" => "Host-level configurations for the servers that can run on this host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => {}
},
"server" => {
"description" => "Servers currently running on the host",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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...]
[View Less]
14 years, 2 months
- 1
- 0
[jBPM Development] - Is anybody doing development in jBPM5?
by Atanu Sen
Atanu Sen [http://community.jboss.org/people/atanus] created the discussion
"Is anybody doing development in jBPM5?"
To view the discussion, visit: http://community.jboss.org/message/580298#580298
--------------------------------------------------------------
Is anybody doing development in jBPM5?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/580298#580298]
Start a new discussion in jBPM …
[View More]Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
[View Less]
14 years, 2 months
- 1
- 0
[jBPM Development] - Human Task Service start up error
by Atanu Sen
Atanu Sen [http://community.jboss.org/people/atanus] created the discussion
"Human Task Service start up error"
To view the discussion, visit: http://community.jboss.org/message/580294#580294
--------------------------------------------------------------
I am running the +*ant start.human.task* script and getting the attached error. Please suggest how to fix this.+
++
[javac] &…
[View More]nbsp; ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:33: package org.jbpm.task.service does not exist
[javac] import org.jbpm.task.service.TaskServiceSession;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:34: package org.jbpm.task.service.mina does not exist
[javac] import org.jbpm.task.service.mina.MinaTaskServer;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:35: package org.drools does not exist
[javac] import org.drools.SystemEventListenerFactory;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:36: package org.mvel2 does not exist
[javac] import org.mvel2.MVEL;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:37: package org.mvel2 does not exist
[javac] import org.mvel2.ParserContext;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:38: package org.mvel2.compiler does not exist
[javac] import org.mvel2.compiler.ExpressionCompiler;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:43: cannot find symbol
[javac] symbol : class EntityManagerFactory
[javac] location: class org.jbpm.DemoTaskService
[javac] EntityManagerFactory emf = Persistence.createEntityManagerFa
ctory("org.jbpm.task");
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:43: cannot find symbol
[javac] symbol : variable Persistence
[javac] location: class org.jbpm.DemoTaskService
[javac] EntityManagerFactory emf = Persistence.createEntityManagerFa
ctory("org.jbpm.task");
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:44: cannot find symbol
[javac] symbol : class TaskService
[javac] location: class org.jbpm.DemoTaskService
[javac] TaskService taskService = new TaskService(emf, SystemEventLi
stenerFactory.getSystemEventListener());
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:44: cannot find symbol
[javac] symbol : class TaskService
[javac] location: class org.jbpm.DemoTaskService
[javac] TaskService taskService = new TaskService(emf, SystemEventLi
stenerFactory.getSystemEventListener());
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:44: cannot find symbol
[javac] symbol : variable SystemEventListenerFactory
[javac] location: class org.jbpm.DemoTaskService
[javac] TaskService taskService = new TaskService(emf, SystemEventLi
stenerFactory.getSystemEventListener());
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:45: cannot find symbol
[javac] symbol : class TaskServiceSession
[javac] location: class org.jbpm.DemoTaskService
[javac] TaskServiceSession taskSession = taskService.createSession()
;
[javac] ^
[javac] C:\jBPM\jbpm-installer\task-service\src\org\jbpm\DemoTaskService.jav
a:49: cannot find symbol
[javac] symbol : class User
[javac] location: class org.jbpm.DemoTaskService
[javac] Map<String, User> users = ( Map<String, User> ) eval( reader
, vars );
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/580294#580294]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
[View Less]
14 years, 2 months
- 1
- 0
[jBPM Development] - Externalization of properties file
by abhijit passi
abhijit passi [http://community.jboss.org/people/passiabhijit] created the discussion
"Externalization of properties file"
To view the discussion, visit: http://community.jboss.org/message/580185#580185
--------------------------------------------------------------
hi
Is there a way by which we can externalize the variables being used in the process using properties files?
thanks
Abhijit
--------------------------------------------------------------
Reply to this message by going to …
[View More]Community
[http://community.jboss.org/message/580185#580185]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
[View Less]
14 years, 2 months
- 1
- 0
[JBoss AS7 Development] - Detyped Representation of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Detyped Representation 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 …
[View More]attributes and operations they expose. These details will be returned in a detyped form, either using the 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.
h3. Representation 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. Representation of the 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
"foo" => {
"description" => "The foo",
"type" => INT,
"max" => 2
}
"bar" => {
"description" => "The bar",
"type" => OBJECT,
"value-type" => {
"size" => INT,
"color" => STRING
}
}
h4. Representation of the description of an Operation
* 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 values.
* reply-properties -- complex structure, or empty -- description of the return value of the operation, with an empty node meaning void.
h4. Representation of the 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
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.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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.)",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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,
"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,
"max-occurs" => 2147483647,
"model-description" => {
"description" => "A named set of subsystem configurations.",
"head-comment-allowed" => true,
"tail-comment-allowed" => true,
"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,
"max-occurs" => 2147483647,
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"socket-binding-group" => {
"description" => "A list of socket binding groups available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"system-property" => {
"description" => "A list of system properties to set on all servers in the domain.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"deployment" => {
"description" => "A list of deployments available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"server-group" => {
"description" => "A list of server groups available for use in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"host" => {
"description" => "Host controllers currently running in the domain",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => {}
}
}
}
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,
"nillable" => false
}},
"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,
"nillable" => false
}},
"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,
"nillable" => false
}},
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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,
"nillable" => false
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"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" => false
}},
"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,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"interface" => {
"description" => "A list of fully specified named network interfaces available for use on the host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"jvm" => {
"description" => "A list of Java Virtual Machine configurations that can be applied ot servers on the host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => "TODO"
},
"server-config" => {
"description" => "Host-level configurations for the servers that can run on this host.",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"model-description" => {}
},
"server" => {
"description" => "Servers currently running on the host",
"min-occurs" => 0,
"max-occurs" => 2147483647,
"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...]
[View Less]
14 years, 2 months
- 1
- 0