Re: [jboss-dev-forums] [JBoss AS7 Development] - Module Inventory
by David Bosschaert
David Bosschaert [http://community.jboss.org/people/bosschaert] commented on the document
"Module Inventory"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16710#comment-6053
--------------------------------------------------
It would be good to spell out exactly what each status value means. For example:
* public: contains API that end users write code against.
* private: does not expose any API but could be an implementation of a public API used by end users at runtime.
* included - part of the Aggregate, I guess? Most likely public but that's not stated.
--------------------------------------------------
13 years
- 1
- 0
[JBoss AS7 Development] - Module Inventory
by David Bosschaert
David Bosschaert [http://community.jboss.org/people/bosschaert] modified the document:
"Module Inventory"
To view the document, visit: http://community.jboss.org/docs/DOC-16710
--------------------------------------------------------------
A full inventory of all modules in the application server. Each module has a status: private, public, or included.
|| *Module Name
* || *Status* || *Justification* ||
| asm.asm |
|
|
| ch.qos.cal10n |
|
|
| com.google.guava |
|
|
| com.h2database.h2 |
|
|
| com.sun.httpserver |
|
|
| com.sun.jsf-impl |
|
|
| com.sun.xml.bind |
|
|
| com.sun.xml.messaging.saaj |
|
|
| javaee.api | Aggregate |
|
| javax.activation.api | Included | EE APIs are included |
| javax.annotation.api | Included | EE APIs are included |
| javax.api | Included | SE API is included |
| javax.ejb.api | Included | EE APIs are included |
| javax.el.api | Included | EE APIs are included |
| javax.enterprise.api | Included | EE APIs are included |
| javax.enterprise.deploy.api | Included | EE APIs are included |
| javax.faces.api | Included | EE APIs are included |
| javax.inject.api | Included | EE APIs are included |
| javax.interceptor.api | Included | EE APIs are included |
| javax.jms.api | Included | EE APIs are included |
| javax.jws.api | Included | EE APIs are included |
| javax.mail.api | Included | EE APIs are included |
| javax.persistence.api | Included | EE APIs are included |
| javax.resource.api | Included | EE APIs are included |
| javax.security.auth.message.api | Included | EE APIs are included |
| javax.security.jacc.api | Included | EE APIs are included |
| javax.servlet.api | Included | EE APIs are included |
| javax.servlet.jsp.api | Included | EE APIs are included |
| javax.servlet.jstl.api | Included | EE APIs are included |
| javax.transaction.api | Included | EE APIs are included |
| javax.validation.api | Included | EE APIs are included |
| javax.wsdl4j.api | Included |
|
| javax.ws.rs.api | Included | EE APIs are included |
| javax.xml.bind.api | Included | EE APIs are included |
| javax.xml.jaxp-provider |
|
|
| javax.xml.registry.api | Included | EE APIs are included |
| javax.xml.rpc.api | Included | EE APIs are included |
| javax.xml.soap.api | Included | EE APIs are included |
| javax.xml.stream.api | Included | EE APIs are included |
| javax.xml.ws.api | Included | EE APIs are included |
| jline |
|
|
| net.sf.cglib |
|
|
| net.sourceforge.cssparser |
|
|
| net.sourceforge.htmlunit |
|
|
| net.sourceforge.nekohtml |
|
|
| org.antlr |
|
|
| org.apache.ant |
|
|
| org.apache.aries.jmx |
|
|
| org.apache.aries.util |
|
|
| org.apache.commons.codec |
|
|
| org.apache.commons.collections |
|
|
| org.apache.commons.io |
|
|
| org.apache.commons.lang |
|
|
| org.apache.commons.logging | public | Users are encouraged to use our provided log APIs |
| org.apache.cxf |
|
|
| org.apache.felix.configadmin |
|
|
| org.apache.httpcomponents |
|
|
| org.apache.james.mime4j |
|
|
| org.apache.log4j | public | Users are encouraged to use our provided log APIs |
| org.apache.neethi |
|
|
| org.apache.santuario.xmlsec |
|
|
| org.apache.ws.commons.xmlschema |
|
|
| org.apache.ws.security |
|
|
| org.apache.xalan |
|
|
| org.apache.xerces |
|
|
| org.codehaus.woodstox |
|
|
| org.dom4j |
|
|
| org.hibernate |
|
|
| org.hibernate.validator |
|
|
| org.hornetq |
|
|
| org.javassist |
|
|
| org.jboss.arquillian.api |
|
|
| org.jboss.arquillian.impl |
|
|
| org.jboss.arquillian.junit |
|
|
| org.jboss.arquillian.protocol.jmx |
|
|
| org.jboss.arquillian.protocol.osgi |
|
|
| org.jboss.arquillian.spi |
|
|
| org.jboss.arquillian.testenricher.cdi |
|
|
| org.jboss.arquillian.testenricher.jmx |
|
|
| org.jboss.arquillian.testenricher.msc |
|
|
| org.jboss.arquillian.testenricher.osgi |
|
|
| org.jboss.arquillian.testenricher.resource |
|
|
| org.jboss.as.aggregate | aggregate (private) |
|
| org.jboss.as.arquillian.common | private |
|
| org.jboss.as.arquillian.protocol.servlet | private |
|
| org.jboss.as.arquillian.service | private |
|
| org.jboss.as.cli | private |
|
| org.jboss.as.clustering | private |
|
| org.jboss.as.connector | private |
|
| org.jboss.as.controller-client | public (?) |
|
| org.jboss.as.controller | private |
|
| org.jboss.as.deployment-repository | private |
|
| org.jboss.as.deployment-scanner | private |
|
| org.jboss.as.domain-controller | private |
|
| org.jboss.as.domain-http-api | public (?) |
|
| org.jboss.as.ee | private |
|
| org.jboss.as.ejb3 | private |
|
| org.jboss.as.example-bootstrap | private |
|
| org.jboss.as.host-controller | private |
|
| org.jboss.as.jaxrs | private |
|
| org.jboss.as.jmx | private |
|
| org.jboss.as.jpa | private |
|
| org.jboss.as.logging | private |
|
| org.jboss.as.messaging | private |
|
| org.jboss.as.naming | private |
|
| org.jboss.as.osgi.configadmin | private |
|
| org.jboss.as.osgi | private |
|
| org.jboss.as.process-controller | private |
|
| org.jboss.as.protocol | private |
|
| org.jboss.as.remoting | private |
|
| org.jboss.as.sar | private |
|
| org.jboss.as.security | private |
|
| org.jboss.as.server | private |
|
| org.jboss.as.standalone | private |
|
| org.jboss.as.threads | private |
|
| org.jboss.as.transactions | private |
|
| org.jboss.as.web | private |
|
| org.jboss.as.webservices | private |
|
| org.jboss.as.webservices.server.integration | private |
|
| org.jboss.as.weld | private |
|
| org.jboss.classfilewriter |
|
|
| org.jboss.common-core | private | This module should be deprecated. |
| org.jboss.deployers.jboss-service-deployer |
|
|
| org.jboss.dmr | public |
|
| org.jboss.ejb3 |
|
|
| org.jboss.integration.jboss-jca-spi |
|
|
| org.jboss.integration.jboss-transaction-spi |
|
|
| org.jboss.interceptor |
|
|
| org.jboss.interceptor.spi |
|
|
| org.jboss.invocation | public |
|
| org.jboss.ironjacamar.api |
|
|
| org.jboss.ironjacamar.impl |
|
|
| org.jboss.ironjacamar.jdbcadapters |
|
|
| org.jboss.jandex |
|
|
| org.jboss.jsfunit.arquillian |
|
|
| org.jboss.jsfunit.core |
|
|
| org.jboss.jsfunit.jsfunit-arquillian-processor |
|
|
| org.jboss.jts.integration |
|
|
| org.jboss.jts |
|
|
| org.jboss.logging | public | Users are encouraged to use our provided log APIs |
| org.jboss.logmanager.log4j |
|
|
| org.jboss.logmanager |
|
|
| org.jboss.marshalling | public |
|
| org.jboss.marshalling.river | public |
|
| org.jboss.metadata |
|
|
| org.jboss.modules | public |
|
| org.jboss.msc | public |
|
| org.jboss.netty |
|
|
| org.jboss.osgi.common | private | JBoss OSGi bundle for common functionality |
| org.jboss.osgi.deployment | private | JBoss OSGi deployment support |
| org.jboss.osgi.framework | private | JBoss OSGi Core Framework |
| org.jboss.osgi.jmx | private | JBoss OSGi Management Extension |
| org.jboss.osgi.resolver | private | A standalone OSGi Resolver |
| org.jboss.osgi.spi | private | JBoss OSGi Service Provider Interface (SPI) |
| org.jboss.osgi.vfs | private | JBoss OSGi Virtual File System |
| org.jboss.remoting3 | public |
|
| org.jboss.resteasy.async-http-servlet-30 |
|
|
| org.jboss.resteasy.resteasy-cdi |
|
|
| org.jboss.resteasy.resteasy-jaxb-provider |
|
|
| org.jboss.resteasy.resteasy-jaxrs |
|
|
| org.jboss.shrinkwrap.api |
|
|
| org.jboss.shrinkwrap.impl |
|
|
| org.jboss.shrinkwrap.spi |
|
|
| org.jboss.staxmapper |
|
|
| org.jboss.stdio |
|
|
| org.jboss.surefire.arquillian-deps |
|
|
| org.jboss.surefire.arquillian-jsfunit-deps |
|
|
| org.jboss.threads | public |
|
| org.jboss.vfs | public | It has been argued that this should be "included" so that deployments using Spring work out of the box. |
| org.jboss.weld.api |
|
|
| org.jboss.weld.core |
|
|
| org.jboss.weld.spi |
|
|
| org.jboss.ws.api |
|
|
| org.jboss.ws.common |
|
|
| org.jboss.ws.cxf.jbossws-cxf-factories |
|
|
| org.jboss.ws.cxf.jbossws-cxf-server |
|
|
| org.jboss.ws.cxf.jbossws-cxf-transports-httpserver |
|
|
| org.jboss.ws.jaxws-client |
|
|
| org.jboss.ws.jaxws-httpserver-httpspi |
|
|
| org.jboss.ws.spi |
|
|
| org.jboss.xnio | public |
|
| org.jboss.xnio.nio |
|
|
| org.jgroups |
|
|
| org.junit |
|
|
| org.osgi.compendium | public | Provides APIs from the OSGi compendium specifications for bundles using OSGi compendium services. |
| org.osgi.core | public | Provides APIs from the OSGi core specifications for people developing OSGi bundles. |
| org.picketbox |
|
|
| org.scannotation.scannotation |
|
|
| org.slf4j.ext |
|
|
| org.slf4j.impl |
|
|
| org.slf4j.jcl-over-slf4j |
|
|
| org.slf4j | public | Users are encouraged to use our provided log APIs |
| org.w3c.css.sac |
|
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16710]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
[JBoss AS7 Development] - Module Inventory
by David Lloyd
David Lloyd [http://community.jboss.org/people/dmlloyd] modified the document:
"Module Inventory"
To view the document, visit: http://community.jboss.org/docs/DOC-16710
--------------------------------------------------------------
A full inventory of all modules in the application server. Each module has a status: private, public, or included.
|| *Module Name
* || *Status* || *Justification* ||
| asm.asm |
|
|
| ch.qos.cal10n |
|
|
| com.google.guava |
|
|
| com.h2database.h2 |
|
|
| com.sun.httpserver |
|
|
| com.sun.jsf-impl |
|
|
| com.sun.xml.bind |
|
|
| com.sun.xml.messaging.saaj |
|
|
| javaee.api | Aggregate |
|
| javax.activation.api | Included | EE APIs are included |
| javax.annotation.api | Included | EE APIs are included |
| javax.api | Included | SE API is included |
| javax.ejb.api | Included | EE APIs are included |
| javax.el.api | Included | EE APIs are included |
| javax.enterprise.api | Included | EE APIs are included |
| javax.enterprise.deploy.api | Included | EE APIs are included |
| javax.faces.api | Included | EE APIs are included |
| javax.inject.api | Included | EE APIs are included |
| javax.interceptor.api | Included | EE APIs are included |
| javax.jms.api | Included | EE APIs are included |
| javax.jws.api | Included | EE APIs are included |
| javax.mail.api | Included | EE APIs are included |
| javax.persistence.api | Included | EE APIs are included |
| javax.resource.api | Included | EE APIs are included |
| javax.security.auth.message.api | Included | EE APIs are included |
| javax.security.jacc.api | Included | EE APIs are included |
| javax.servlet.api | Included | EE APIs are included |
| javax.servlet.jsp.api | Included | EE APIs are included |
| javax.servlet.jstl.api | Included | EE APIs are included |
| javax.transaction.api | Included | EE APIs are included |
| javax.validation.api | Included | EE APIs are included |
| javax.wsdl4j.api | Included |
|
| javax.ws.rs.api | Included | EE APIs are included |
| javax.xml.bind.api | Included | EE APIs are included |
| javax.xml.jaxp-provider |
|
|
| javax.xml.registry.api | Included | EE APIs are included |
| javax.xml.rpc.api | Included | EE APIs are included |
| javax.xml.soap.api | Included | EE APIs are included |
| javax.xml.stream.api | Included | EE APIs are included |
| javax.xml.ws.api | Included | EE APIs are included |
| jline |
|
|
| net.sf.cglib |
|
|
| net.sourceforge.cssparser |
|
|
| net.sourceforge.htmlunit |
|
|
| net.sourceforge.nekohtml |
|
|
| org.antlr |
|
|
| org.apache.ant |
|
|
| org.apache.aries.jmx |
|
|
| org.apache.aries.util |
|
|
| org.apache.commons.codec |
|
|
| org.apache.commons.collections |
|
|
| org.apache.commons.io |
|
|
| org.apache.commons.lang |
|
|
| org.apache.commons.logging | public | Users are encouraged to use our provided log APIs |
| org.apache.cxf |
|
|
| org.apache.felix.configadmin |
|
|
| org.apache.httpcomponents |
|
|
| org.apache.james.mime4j |
|
|
| org.apache.log4j | public | Users are encouraged to use our provided log APIs |
| org.apache.neethi |
|
|
| org.apache.santuario.xmlsec |
|
|
| org.apache.ws.commons.xmlschema |
|
|
| org.apache.ws.security |
|
|
| org.apache.xalan |
|
|
| org.apache.xerces |
|
|
| org.codehaus.woodstox |
|
|
| org.dom4j |
|
|
| org.hibernate |
|
|
| org.hibernate.validator |
|
|
| org.hornetq |
|
|
| org.javassist |
|
|
| org.jboss.arquillian.api |
|
|
| org.jboss.arquillian.impl |
|
|
| org.jboss.arquillian.junit |
|
|
| org.jboss.arquillian.protocol.jmx |
|
|
| org.jboss.arquillian.protocol.osgi |
|
|
| org.jboss.arquillian.spi |
|
|
| org.jboss.arquillian.testenricher.cdi |
|
|
| org.jboss.arquillian.testenricher.jmx |
|
|
| org.jboss.arquillian.testenricher.msc |
|
|
| org.jboss.arquillian.testenricher.osgi |
|
|
| org.jboss.arquillian.testenricher.resource |
|
|
| org.jboss.as.aggregate | aggregate (private) |
|
| org.jboss.as.arquillian.common | private |
|
| org.jboss.as.arquillian.protocol.servlet | private |
|
| org.jboss.as.arquillian.service | private |
|
| org.jboss.as.cli | private |
|
| org.jboss.as.clustering | private |
|
| org.jboss.as.connector | private |
|
| org.jboss.as.controller-client | public (?) |
|
| org.jboss.as.controller | private |
|
| org.jboss.as.deployment-repository | private |
|
| org.jboss.as.deployment-scanner | private |
|
| org.jboss.as.domain-controller | private |
|
| org.jboss.as.domain-http-api | public (?) |
|
| org.jboss.as.ee | private |
|
| org.jboss.as.ejb3 | private |
|
| org.jboss.as.example-bootstrap | private |
|
| org.jboss.as.host-controller | private |
|
| org.jboss.as.jaxrs | private |
|
| org.jboss.as.jmx | private |
|
| org.jboss.as.jpa | private |
|
| org.jboss.as.logging | private |
|
| org.jboss.as.messaging | private |
|
| org.jboss.as.naming | private |
|
| org.jboss.as.osgi.configadmin | private |
|
| org.jboss.as.osgi | private |
|
| org.jboss.as.process-controller | private |
|
| org.jboss.as.protocol | private |
|
| org.jboss.as.remoting | private |
|
| org.jboss.as.sar | private |
|
| org.jboss.as.security | private |
|
| org.jboss.as.server | private |
|
| org.jboss.as.standalone | private |
|
| org.jboss.as.threads | private |
|
| org.jboss.as.transactions | private |
|
| org.jboss.as.web | private |
|
| org.jboss.as.webservices | private |
|
| org.jboss.as.webservices.server.integration | private |
|
| org.jboss.as.weld | private |
|
| org.jboss.classfilewriter |
|
|
| org.jboss.common-core | private | This module should be deprecated. |
| org.jboss.deployers.jboss-service-deployer |
|
|
| org.jboss.dmr | public |
|
| org.jboss.ejb3 |
|
|
| org.jboss.integration.jboss-jca-spi |
|
|
| org.jboss.integration.jboss-transaction-spi |
|
|
| org.jboss.interceptor |
|
|
| org.jboss.interceptor.spi |
|
|
| org.jboss.invocation | public |
|
| org.jboss.ironjacamar.api |
|
|
| org.jboss.ironjacamar.impl |
|
|
| org.jboss.ironjacamar.jdbcadapters |
|
|
| org.jboss.jandex |
|
|
| org.jboss.jsfunit.arquillian |
|
|
| org.jboss.jsfunit.core |
|
|
| org.jboss.jsfunit.jsfunit-arquillian-processor |
|
|
| org.jboss.jts.integration |
|
|
| org.jboss.jts |
|
|
| org.jboss.logging | public | Users are encouraged to use our provided log APIs |
| org.jboss.logmanager.log4j |
|
|
| org.jboss.logmanager |
|
|
| org.jboss.marshalling | public |
|
| org.jboss.marshalling.river | public |
|
| org.jboss.metadata |
|
|
| org.jboss.modules | public |
|
| org.jboss.msc | public |
|
| org.jboss.netty |
|
|
| org.jboss.osgi.common |
|
|
| org.jboss.osgi.deployment |
|
|
| org.jboss.osgi.framework |
|
|
| org.jboss.osgi.jmx |
|
|
| org.jboss.osgi.resolver |
|
|
| org.jboss.osgi.spi |
|
|
| org.jboss.osgi.vfs |
|
|
| org.jboss.remoting3 | public |
|
| org.jboss.resteasy.async-http-servlet-30 |
|
|
| org.jboss.resteasy.resteasy-cdi |
|
|
| org.jboss.resteasy.resteasy-jaxb-provider |
|
|
| org.jboss.resteasy.resteasy-jaxrs |
|
|
| org.jboss.shrinkwrap.api |
|
|
| org.jboss.shrinkwrap.impl |
|
|
| org.jboss.shrinkwrap.spi |
|
|
| org.jboss.staxmapper |
|
|
| org.jboss.stdio |
|
|
| org.jboss.surefire.arquillian-deps |
|
|
| org.jboss.surefire.arquillian-jsfunit-deps |
|
|
| org.jboss.threads | public |
|
| org.jboss.vfs | public | It has been argued that this should be "included" so that deployments using Spring work out of the box. |
| org.jboss.weld.api |
|
|
| org.jboss.weld.core |
|
|
| org.jboss.weld.spi |
|
|
| org.jboss.ws.api |
|
|
| org.jboss.ws.common |
|
|
| org.jboss.ws.cxf.jbossws-cxf-factories |
|
|
| org.jboss.ws.cxf.jbossws-cxf-server |
|
|
| org.jboss.ws.cxf.jbossws-cxf-transports-httpserver |
|
|
| org.jboss.ws.jaxws-client |
|
|
| org.jboss.ws.jaxws-httpserver-httpspi |
|
|
| org.jboss.ws.spi |
|
|
| org.jboss.xnio | public |
|
| org.jboss.xnio.nio |
|
|
| org.jgroups |
|
|
| org.junit |
|
|
| org.osgi.compendium |
|
|
| org.osgi.core |
|
|
| org.picketbox |
|
|
| org.scannotation.scannotation |
|
|
| org.slf4j.ext |
|
|
| org.slf4j.impl |
|
|
| org.slf4j.jcl-over-slf4j |
|
|
| org.slf4j | public | Users are encouraged to use our provided log APIs |
| org.w3c.css.sac |
|
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16710]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
[JBoss AS7 Development] - Module Inventory
by David Lloyd
David Lloyd [http://community.jboss.org/people/dmlloyd] created the document:
"Module Inventory"
To view the document, visit: http://community.jboss.org/docs/DOC-16710
--------------------------------------------------------------
A full inventory of all modules in the application server. Each module has a status: private, public, or included.
|| *Module Name
* || *Status* || *Justification* ||
| asm.asm |
|
|
| ch.qos.cal10n |
|
|
| com.google.guava |
|
|
| com.h2database.h2 |
|
|
| com.sun.httpserver |
|
|
| com.sun.jsf-impl |
|
|
| com.sun.xml.bind |
|
|
| com.sun.xml.messaging.saaj |
|
|
| javaee.api |
|
|
| javax.activation.api |
|
|
| javax.annotation.api |
|
|
| javax.api |
|
|
| javax.ejb.api |
|
|
| javax.el.api |
|
|
| javax.enterprise.api |
|
|
| javax.enterprise.deploy.api |
|
|
| javax.faces.api |
|
|
| javax.inject.api |
|
|
| javax.interceptor.api |
|
|
| javax.jms.api |
|
|
| javax.jws.api |
|
|
| javax.mail.api |
|
|
| javax.persistence.api |
|
|
| javax.resource.api |
|
|
| javax.security.auth.message.api |
|
|
| javax.security.jacc.api |
|
|
| javax.servlet.api |
|
|
| javax.servlet.jsp.api |
|
|
| javax.servlet.jstl.api |
|
|
| javax.transaction.api |
|
|
| javax.validation.api |
|
|
| javax.wsdl4j.api |
|
|
| javax.ws.rs.api |
|
|
| javax.xml.bind.api |
|
|
| javax.xml.jaxp-provider |
|
|
| javax.xml.registry.api |
|
|
| javax.xml.rpc.api |
|
|
| javax.xml.soap.api |
|
|
| javax.xml.stream.api |
|
|
| javax.xml.ws.api |
|
|
| jline |
|
|
| net.sf.cglib |
|
|
| net.sourceforge.cssparser |
|
|
| net.sourceforge.htmlunit |
|
|
| net.sourceforge.nekohtml |
|
|
| org.antlr |
|
|
| org.apache.ant |
|
|
| org.apache.aries.jmx |
|
|
| org.apache.aries.util |
|
|
| org.apache.commons.codec |
|
|
| org.apache.commons.collections |
|
|
| org.apache.commons.io |
|
|
| org.apache.commons.lang |
|
|
| org.apache.commons.logging |
|
|
| org.apache.cxf |
|
|
| org.apache.felix.configadmin |
|
|
| org.apache.httpcomponents |
|
|
| org.apache.james.mime4j |
|
|
| org.apache.log4j |
|
|
| org.apache.neethi |
|
|
| org.apache.santuario.xmlsec |
|
|
| org.apache.ws.commons.xmlschema |
|
|
| org.apache.ws.security |
|
|
| org.apache.xalan |
|
|
| org.apache.xerces |
|
|
| org.codehaus.woodstox |
|
|
| org.dom4j |
|
|
| org.hibernate |
|
|
| org.hibernate.validator |
|
|
| org.hornetq |
|
|
| org.javassist |
|
|
| org.jboss.arquillian.api |
|
|
| org.jboss.arquillian.impl |
|
|
| org.jboss.arquillian.junit |
|
|
| org.jboss.arquillian.protocol.jmx |
|
|
| org.jboss.arquillian.protocol.osgi |
|
|
| org.jboss.arquillian.spi |
|
|
| org.jboss.arquillian.testenricher.cdi |
|
|
| org.jboss.arquillian.testenricher.jmx |
|
|
| org.jboss.arquillian.testenricher.msc |
|
|
| org.jboss.arquillian.testenricher.osgi |
|
|
| org.jboss.arquillian.testenricher.resource |
|
|
| org.jboss.as.aggregate |
|
|
| org.jboss.as.arquillian.common |
|
|
| org.jboss.as.arquillian.protocol.servlet |
|
|
| org.jboss.as.arquillian.service |
|
|
| org.jboss.as.cli |
|
|
| org.jboss.as.clustering |
|
|
| org.jboss.as.connector |
|
|
| org.jboss.as.controller-client |
|
|
| org.jboss.as.controller |
|
|
| org.jboss.as.deployment-repository |
|
|
| org.jboss.as.deployment-scanner |
|
|
| org.jboss.as.domain-controller |
|
|
| org.jboss.as.domain-http-api |
|
|
| org.jboss.as.ee |
|
|
| org.jboss.as.ejb3 |
|
|
| org.jboss.as.example-bootstrap |
|
|
| org.jboss.as.host-controller |
|
|
| org.jboss.as.jaxrs |
|
|
| org.jboss.as.jmx |
|
|
| org.jboss.as.jpa |
|
|
| org.jboss.as.logging |
|
|
| org.jboss.as.messaging |
|
|
| org.jboss.as.naming |
|
|
| org.jboss.as.osgi.configadmin |
|
|
| org.jboss.as.osgi |
|
|
| org.jboss.as.process-controller |
|
|
| org.jboss.as.protocol |
|
|
| org.jboss.as.remoting |
|
|
| org.jboss.as.sar |
|
|
| org.jboss.as.security |
|
|
| org.jboss.as.server |
|
|
| org.jboss.as.standalone |
|
|
| org.jboss.as.threads |
|
|
| org.jboss.as.transactions |
|
|
| org.jboss.as.web |
|
|
| org.jboss.as.webservices |
|
|
| org.jboss.as.webservices.server.integration |
|
|
| org.jboss.as.weld |
|
|
| org.jboss.classfilewriter |
|
|
| org.jboss.common-core |
|
|
| org.jboss.deployers.jboss-service-deployer |
|
|
| org.jboss.dmr |
|
|
| org.jboss.ejb3 |
|
|
| org.jboss.integration.jboss-jca-spi |
|
|
| org.jboss.integration.jboss-transaction-spi |
|
|
| org.jboss.interceptor |
|
|
| org.jboss.interceptor.spi |
|
|
| org.jboss.invocation |
|
|
| org.jboss.ironjacamar.api |
|
|
| org.jboss.ironjacamar.impl |
|
|
| org.jboss.ironjacamar.jdbcadapters |
|
|
| org.jboss.jandex |
|
|
| org.jboss.jsfunit.arquillian |
|
|
| org.jboss.jsfunit.core |
|
|
| org.jboss.jsfunit.jsfunit-arquillian-processor |
|
|
| org.jboss.jts.integration |
|
|
| org.jboss.jts |
|
|
| org.jboss.logging |
|
|
| org.jboss.logmanager.log4j |
|
|
| org.jboss.logmanager |
|
|
| org.jboss.marshalling |
|
|
| org.jboss.marshalling.river |
|
|
| org.jboss.metadata |
|
|
| org.jboss.modules |
|
|
| org.jboss.msc |
|
|
| org.jboss.netty |
|
|
| org.jboss.osgi.common |
|
|
| org.jboss.osgi.deployment |
|
|
| org.jboss.osgi.framework |
|
|
| org.jboss.osgi.jmx |
|
|
| org.jboss.osgi.resolver |
|
|
| org.jboss.osgi.spi |
|
|
| org.jboss.osgi.vfs |
|
|
| org.jboss.remoting3 |
|
|
| org.jboss.resteasy.async-http-servlet-30 |
|
|
| org.jboss.resteasy.resteasy-cdi |
|
|
| org.jboss.resteasy.resteasy-jaxb-provider |
|
|
| org.jboss.resteasy.resteasy-jaxrs |
|
|
| org.jboss.shrinkwrap.api |
|
|
| org.jboss.shrinkwrap.impl |
|
|
| org.jboss.shrinkwrap.spi |
|
|
| org.jboss.staxmapper |
|
|
| org.jboss.stdio |
|
|
| org.jboss.surefire.arquillian-deps |
|
|
| org.jboss.surefire.arquillian-jsfunit-deps |
|
|
| org.jboss.threads |
|
|
| org.jboss.vfs |
|
|
| org.jboss.weld.api |
|
|
| org.jboss.weld.core |
|
|
| org.jboss.weld.spi |
|
|
| org.jboss.ws.api |
|
|
| org.jboss.ws.common |
|
|
| org.jboss.ws.cxf.jbossws-cxf-factories |
|
|
| org.jboss.ws.cxf.jbossws-cxf-server |
|
|
| org.jboss.ws.cxf.jbossws-cxf-transports-httpserver |
|
|
| org.jboss.ws.jaxws-client |
|
|
| org.jboss.ws.jaxws-httpserver-httpspi |
|
|
| org.jboss.ws.spi |
|
|
| org.jboss.xnio |
|
|
| org.jboss.xnio.nio |
|
|
| org.jgroups |
|
|
| org.junit |
|
|
| org.osgi.compendium |
|
|
| org.osgi.core |
|
|
| org.picketbox |
|
|
| org.scannotation.scannotation |
|
|
| org.slf4j.ext |
|
|
| org.slf4j.impl |
|
|
| org.slf4j.jcl-over-slf4j |
|
|
| org.slf4j |
|
|
| org.w3c.css.sac |
|
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16710]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
Re: [jboss-dev-forums] [IronJacamar Development] - IronJacamar Management
by Andrig Miller
Andrig Miller [http://community.jboss.org/people/andy.miller] commented on the document
"IronJacamar Management"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16674#comment-6050
--------------------------------------------------
In looking over this I don't see any real holes, but I do have a couple of questions. How does the CachedConnectionManager play into the JCA container now? Is it still a hard dependency? If its still there, it would be really great to be able to remove it completely from the configuration.
I like the fact that you will be able to turn on and off the statistics, as we will be able to directly measure the difference, and it probably helps with the benchmarking activities. The one statistic that seems to be missing is the max connection count in use, which is probably also the worst from a performance perspective. Was that intentional? It seems like you could just use the created count for that, if it was greater than the min and less than the max anyway.
--------------------------------------------------
13 years
- 1
- 0
[JBoss AS7 Development] - Multiple instances of JBoss AS7 on the same machine
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Multiple instances of JBoss AS7 on the same machine"
To view the document, visit: http://community.jboss.org/docs/DOC-16705
--------------------------------------------------------------
h4. Overview:
This wiki explains how multiple instances of JBoss AS7 +standalone+ server, on single physical system, can be started simultaneously.
h4. Approach#1
[Tested against JBoss AS7.0.0 Beta2 and AS7 upstream dated April 8 2011]
In this approach we will create multiple copies of JBoss AS7 on a single system.
* Download JBoss AS7. And unzip it to some location. Let's call this instance <jboss-as-7-one>
* As a sanity test, just start this server once, by running the following script from the <jboss-as-7-one>/bin folder:
jpai@jpai-laptop:bin$ ./standalone.sh
* Make sure the server starts without any errors. Once it has started, shutdown the server by using Ctrl + C
* Let's now copy the entire <jboss-as-7-one> instance to <jboss-as-7-two>. We now have 2 copies of JBoss AS7 on our system.
* Our next step is to configure the second instance to use a different IP address to bind the services to. By default, <jboss-as-7-one> instance uses 127.0.0.1 as the IP address to bind the services to. This in configured in JBOSS_HOME/standalone/configuration/standalone.xml file (only relevant sections pasted below):
...
<management-interfaces>
<native-interface interface="default" port="9999"/>
<http-interface interface="default" port="9990"/>
</management-interfaces>
...
<interfaces>
<interface name="default">
<inet-address value="127.0.0.1"/>
</interface>
<interface name="any">
<any-address/>
</interface>
<interface name="complex">
<any>
<subnet-match value="192.168.0.0/16"/>
<public-address/>
</any>
<not>
<site-local-address/>
</not>
<up/>
<multicast/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="default">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8447"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="txn-socket-process-id" port="4714"/>
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
As can be seen, the management interface and the socket bindings, all use the interface named "default", which binds to 127.0.0.1.
* Now for <jboss-as-7-two> let's configure this file to use a different interface.
* Open the <jboss-as-7-two>/standalone/configuration/standalone.xml in a text editor and a custom interface to the <interfaces> section. In this example, we'll name the new interface "specific-ip-interface" and let it bind to a specific IP XXX.YYY.AAA.BBB (should be a valid IP address). So here's the new interface definition:
<interfaces>
<interface name="default">
<inet-address value="127.0.0.1"/>
</interface>
<!-- New interface for our second instance -->
<interface name="specific-ip-interface">
<inet-address value="XXX.YYY.AAA.BBB"/>
</interface>
<interface name="any">
<any-address/>
</interface>
<interface name="complex">
<any>
<subnet-match value="192.168.0.0/16"/>
<public-address/>
</any>
<not>
<site-local-address/>
</not>
<up/>
<multicast/>
</interface>
</interfaces>
* Our next step is to let the socket bindings and the management interface, use this new interface instead of the default one.
* So continue editing the <jboss-as-7-two>/standalone/configuration/standalone.xml and point the management interface and socket bindings to use this new interface as follows:
...
<management-interfaces>
<native-interface interface="specific-ip-interface" port="9999"/>
<http-interface interface="specific-ip-interface" port="9990"/>
</management-interfaces>
...
<interfaces>
<interface name="default">
<inet-address value="127.0.0.1"/>
</interface>
<!-- New interface for our second instance -->
<interface name="specific-ip-interface">
<inet-address value="XXX.YYY.AAA.BBB"/>
</interface>
<interface name="any">
<any-address/>
</interface>
<interface name="complex">
<any>
<subnet-match value="192.168.0.0/16"/>
<public-address/>
</any>
<not>
<site-local-address/>
</not>
<up/>
<multicast/>
</interface>
</interfaces>
<socket-binding-group name="standard-sockets" default-interface="specific-ip-interface">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8447"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="txn-socket-process-id" port="4714"/>
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
* Save the changes. That's it for configurations. Now let's start these individual instances.
* From the command prompt, go to <jboss-as-7-one>/bin and run the following command:
jpai@jpai-laptop:jboss-as-7-one/bin$ ./standalone.sh
* Run the same command from <jboss-as-7-two>/bin:
jpai@jpai-laptop:jboss-as-7-two/bin$ ./standalone.sh
You'll now have 2 different instances of JBoss AS7 running on the same physical system.
h4. Approach#2(?)
Use the same interface but bind to different ports:
...
<management-interfaces>
<native-interface interface="default" port="19999"/>
<http-interface interface="default" port="19990"/>
</management-interfaces>
...
<socket-binding-group name="standard-sockets" default-interface="default" port-offset="100">
<socket-binding name="jndi" port="1099"/>
<socket-binding name="jmx-connector-registry" port="1090"/>
<socket-binding name="jmx-connector-server" port="1091"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8447"/>
<socket-binding name="osgi-http" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<socket-binding name="txn-socket-process-id" port="4714"/>
<socket-binding name="messaging" port="5445"/>
<socket-binding name="messaging-throughput" port="5455"/>
</socket-binding-group>
The key is the "port-offset" param on the socket-binding-group param. With that set, all sockets (except those whose socket-binding element has a 'fixed-port="true"' attribute) will have their port number offset by 100 from the declared value.
All sockets, that is, except the 2 management interfaces, which (currently at least) aren't getting their socket configuration from the socket-binding-group, hence the new port values in the example above.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16705]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
Re: [jboss-dev-forums] [JBoss AS7 Development] - JBoss AS7 User Guide
by Matt Drees
Matt Drees [http://community.jboss.org/people/matt.drees] commented on the document
"JBoss AS7 User Guide"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16068#comment-6048
--------------------------------------------------
I fixed the other two jboss_7_0.xsd links in the document.
--------------------------------------------------
13 years
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Matt Drees
Matt Drees [http://community.jboss.org/people/matt.drees] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-development mailing list.
AS 7 is currently in "Beta" status, so users should not expect all of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
In addition to this, please reference http://community.jboss.org/en/jbossas/dev/jboss_as7_development?view=tags... all articles tagged #jboss_7_userguide
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See "Domain Mode vs. Standalone Mode" below for more on what those choices mean.
If you want to work in domain mode, open a terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight Process Controller process that is responsible for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open a terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Host Controller process. The Host Controllers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a Domain Controller, a Host Controller and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h4. Deciding Between Domain Mode and Standalone Mode
Which use cases are appropriate for domain mode and which are appropriate for standalone mode? Domain mode is all about coordinated multi-server management -- with it JBoss AS provides a central point through which users can manage multiple servers, with rich capabilities to keep those servers' configurations consistent and the ability to roll out configuration changes (including deployments) to the servers in a coordinated fashion.
It's important to understand that domain mode and standalone mode are all about how your servers are managed, not what capabilities they have to service end user requests. This distinction is particularly important when it comes to high availability clusters. The current AS 7 beta1 release does not support HA functionality. However, it's important to understand that once HA functionality is added in a later beta, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
So, given all that:
* A single server installation gains nothing from domain mode, so standalone mode is a better choice.
* For multi-server production environments, the choice of domain mode versus standalone mode comes down to whether the user wants to use the centralized management capability domain mode provides. Some enterprises have developed their own sophisticated multi-server management capabilities and are comfortable coordinating changes across a number of independent JBoss AS instances. For these enterprises, a multi-server architecture comprised of individual standalone mode AS instances is a good option.
* Standalone mode is better suited for most development scenarios. In particular, there is no "domain mode" for embedding JBoss AS; e.g. in an Arquillian-based testsuite. Any individual server configuration that can be achieved in domain mode can also be achieved in standalone mode, so even if the application being developed will eventually run in production on a domain mode installation, much (probably most) development can be done using standalone mode.
* Domain mode can be helpful in some advanced development scenarios; i.e. those involving interaction between multiple AS instances. Developers may find that setting up various servers as members of a domain is an efficient way to launch a multi-server cluster.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Host Controller and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Host Controller that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Controller and Host Controller write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide. (Not used in Beta1, removed for Beta2.)
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilize the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide. (Not used in Beta1, removed for Beta2.)
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Host Controller is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <domain> element, to learn more about configuration of a Domain Controller.
*host.xml* -- configuration file for the Host Controller that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Host Controller is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Host Controller to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of a Host Controller.
*logging.properties* -- Contains the logging configuration for the Host Controller and Process Controller that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2. General Configuration Concepts
In both Domain Mode and Standalone Mode a number of common configuration concepts apply:
h4. Extensions
An extension is a module that extends the core capabilities of the server. The AS core is very simple and lightweight; most of the capabilities people associate with an application server are provided via extensions. An extension is packaged as a module in the modules folder. The user indicates that they want a particular extension to be available by including an <extension/> element naming its module in the domain.xml or standalone.xml file.
<extensions>
...
<extension module="org.jboss.as.transactions"/>
<extension module="org.jboss.as.web" />
<extension module="org.jboss.as.webservices" />
<extension module="org.jboss.as.weld" />
</extensions>
h4. Paths
A logical name for a filesystem path. The domain.xml, host.xml and standalone.xml configurations all include a section where paths can be declared. Other sections of the configuration can then reference those paths by their logical name, rather than having to include the full details of the path (which may vary on different machines). For example, the logging subsystem configuration includes a reference to the "jboss.server.log.dir" path that points to the server's "log" directory.
<file relative-to="jboss.server.log.dir" path="server.log"/>
The AS automatically provides a number of standard paths without any need for the user to configure them in a configuration file:
* jboss.home - the root directory of the JBoss AS distribution
* user.home - user's home directory
* user.dir - user's current working directory
* java.home - java installation directory
* jboss.server.base.dir - root directory for an individual server instance
* jboss.server.data.dir - directory the server will use for persistent data file storage
* jboss.server.log.dir - directory the server will use for log file storage
* jboss.server.tmp.dir - directory the server will use for temporary file storage
* jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances (domain mode only)
Users can add their own paths or override all except the first 5 of the above by adding a <path/> element to their configuration file.
<path name="example" path="example" relative-to="jboss.server.data.dir"/>
See the XSD for details.
A <path/> element in a domain.xml need not include anything more than the name attribute; i.e. it need not include any information indicating what the actual filesystem path is:
<path name="x"/>
Such a configuration simply says, "There is a path named 'x' that other parts of the domain.xml configuration can reference. The actual filesystem location pointed to by 'x' is host-specific and will be specified in each machine's host.xml file." If this approach is used, there must be a path element in each machine's host.xml that specifies what the actual filesystem path is:
<path name="x" path="/var/x" />
h4. Interfaces
h4.
A logical name for a network interface/IP address/host name to which sockets can be bound. The domain.xml, host.xml and standalone.xml configurations all include a section where interfaces can be declared. Other sections of the configuration can then reference those interfaces by their logical name, rather than having to include the full details of the interface (which may vary on different machines).
An interface configuration includes the logical name of the interface as well as information specifying the criteria to use for resolving the actual physical address to use. The criteria is one of two types: either a single element indicating that the interface should be bound to a wildcard address, or a set of one or more characteristics that an interface or address must have in order to be a valid match.
<interface name="global">
<!-- Use the wildcard address -->
<any-address/>
</interface>
<interface name="external">
<nic name="eth0"/>
</interface>
<interface name="default">
<!-- Match any interface/address on the right subnet if it's
up, supports multicast and isn't point-to-point -->
<subnet-match value="192.168.0.0/16"/>
<up/>
<multicast/>
<not>
<point-to-point/>
</not>
</interface>
<interface name="loopback">
<inet-address value="127.0.0.1"/>
</interface>
See the XSD for full details on the various criteria options.
An <interface/> element in a domain.xml need not include anything more than the name attribute; i.e. it need not include any information indicating what the actual IP address associated with the name is:
<interface name="internal"/>
Such a configuration simply says, "There is an interface named 'internal' that other parts of the domain.xml configuration can reference. The actual IP address pointed to by 'internal' is host-specific and will be specified in each machine's host.xml file." If this approach is used, there must be an interface element in each machine's host.xml that specifies the criteria for determining the IP address:
<interface name="internal">
<nic name="eth1"/>
</interface>
h4. Socket Bindings and Socket Binding Groups
A socket binding is a named configuration for a socket.
The domain.xml and standalone.xml configurations both include a section where named socket configurations can be declared. Other sections of the configuration can then reference those sockets by their logical name, rather than having to include the full details of the socket configuration (which may vary on different machines).
A socket binding includes the following information:
* name -- logical name of the socket configuration that should be used elsewhere in the configuration
* port -- base port to which a socket based on this configuration should be bound. (Note that servers can be configured to override this base value by applying an increment or decrement to all port values. See below for more details.)
* interface (optional) -- logical name (see "Interfaces" above) of the interface to which a socket based on this configuration should be bound
* multicast-address (optional) -- if the socket will be used for multicast, the multicast address to use
* multicast-port (optional) -- if the socket will be used for multicast, the multicast port to use
* fixed-port (optional, defaults to false) -- if true, declares that the value of port should always be used for the socket and should not be overridden
Socket binding configurations are organized inside a <socket-binding-group/> element. That element also includes a default-interface attribute; that interface will be used for any bindings that do not specify their interface attribute.
h4. System Properties
System property values can be set in a number of places in
domain.xml, host.xml and standalone.xml. The values in standalone.xml are set as part of the server boot process. Values in domain.xml and host.xml are applied to servers when they are launched.
h4. Profiles and Subsystems
The most significant part of the configuration in domain.xml and standalone.xml is the configuration of one (in standalone.xml) or more (in domain.xml) "profiles". A profile is a named set of subsystem configurations. A subsystem is an added set of capabilities added to the core server by an extension (see "Extensions" above). A subsystem provides servlet handling capabilities; a subsystem provides an EJB container; a subsystem provides JTA, etc. A profile is a named list of subsystems, along with the details of each subsystem's configuration. A profile with a large number of subsystems results in a server with a large set of capabilities. A profile with a small, focused set of subsystems will have fewer capabilities but a smaller footprint.
The content of an individual profile configuration looks largely the same in domain.xml and standalone.xml. The only difference is standalone.xml is only allowed to have a single profile element (the profile the server will run), while domain.xml can have many profiles, each of which can be mapped to one or more groups of servers. The profile element in domain.xml also supports an <includes profile="another_profile"/> tag which allows configuration reuse whereby several more complex profiles can include the contents of simpler profiles.
The contents of individual subsystem configurations look exactly the same between domain.xml and standalone.xml.
h2. Standalone Mode Configuration Concepts
In addition to the general configuration concepts described above, the following concepts are specific to an AS instance running in standalone mode.
h4. Server Name
The root <server/> element in standalone.xml include a name attribute. If set, the value becomes the name of the server. If not set
If not set, defaults to the runtime value of java.net.InetAddress.getLocalHost().getHostName(). Users are encouraged to use distinct names for all servers in the operational environment. The server name is made available to all services running in the server.
h4. Paths and Interfaces
As mentioned above, domain.xml supports not fully describing a path (by providing the actual filesystem path) or an interface (by providing criteria to determine the IP address to use). This is not supported in standalone.xml.
h4. Socket Binding and Avoiding Port Conflicts
In standalone.xml, only a single <socket-binding-group/> element is allowed.
In standalone.xml, the <socket-binding-group/> element can also include a port-offset attribute. The value of this attribute will be added to the port attribute value for any binding to derive the actual port to use for the socket. Setting the port-offset to a value other than zero allows multiple AS instances with the same socket binding and interface configurations to run on the same machine without having port conflicts.
In domain.xml the <socket-binding-group/> element does not include a port-offset attribute; see "Domain Mode Configuration Concepts" below for more on how an equivalent configuration is done.
h4. Profiles
As noted above, only a single profile element is allowed in standalone.xml.
h4. Deployments
The standalone.xml file includes a section listing the deployment content available for use on the server. Deployment content is made available for use either by uploading it using the AS's management APIs, or by configuring a deployment scanner service and placing the content in the folder scanned by that service (i.e. the deployments/ folder.)
Each deployment element includes the following information:
* name -- Unique identifier of the deployment. Must be unique across all deployments.
* runtime-name -- name by which the deployment should be known within the runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as name, but in some cases users may wish to have two deployments with the same runtime-name may (e.g. two versions of "foo.war") both available in the deployment content repository, in which case the deployments would need to have distinct name values but would have the same runtime-name
* hash -- a hash of the deployment content, created by the server when the content was uploaded. The server uses the hash internally to find content in the repository.
* start -- a boolean flag indicating whether the content is actually deployed into the runtime (and should be automatically deployed when the server starts.)
h2. Domain Mode Configuration Concepts
In addition to the general configuration concepts described above, the following concepts are specific to configuring a set of JBoss AS instances in domain mode.
h4. Domain.xml vs Host.xml
Domain configuration is divided into two portions: a set of configuration elements that is consistent on all hosts across the domain (stored in the domain.xml file on the host that is acting as the Domain Controller), and a set of configuration elements that differs on each host (stored in a host.xml on each host). Most configuration should come from the domain.xml; the host.xml is meant to be limited to details that need to vary from one host to another (e.g. IP addresses, filesystem paths, and, most significantly the names of the servers that should run on each host.
Each host's Host Controller is responsible for launching the servers configured in its host.xml file. To do this the Host Controller gets a copy of the domain-wide configuration from the Domain Controller, extracts the portion of the domain-wide configuration that is relevant to the server (e.g. the details of the profile the server is configured to run), applies host-specific information (e.g. the IP addresses to use for named interfaces), and creates a server-specific configuration. The Host Controller then launches the server process and provides it its configuration. If that server-specific configuration were represented in XML form, it would look the same as a standalone.xml file -- the Host Controller essentially synthesizes a standalone.xml from the relevant domain.xml and host.xml content.
h3. Domain.xml Configuration Concepts
h4. Profiles
As noted above, the domain.xml file can contain multiple profiles. Different servers in the domain can run different profiles.
h4. Paths and Interfaces
As discussed above, path and interface elements in domain.xml can legally include nothing more than the name of the path or interface, in which case each host.xml is responsible for specifying the details of the path or interface.
h4. Deployments
The Domain Controller maintains a repository of deployment content that is available for use in the servers in the domain.
The domain.xml file includes a section listing the deployment content available for use in the domain. Deployment content is made available for use by uploading it using the AS's management APIs.
Each deployment element includes the following information:
* name -- Unique identifier of the deployment. Must be unique across all deployments in the domain.
* runtime-name -- name by which the deployment should be known within the runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as name, but in some cases users may wish to have two deployments with the same runtime-name may (e.g. two versions of "foo.war") both available in the deployment content repository, in which case the deployments would need to have distinct name values but would have the same runtime-name
* hash -- a hash of the deployment content, created by the server when the content was uploaded. The server uses the hash internally to find content in the repository.
Note that the fact that a deployment is listed in the domain-level deployments listing does not mean it will actually be deployed on any servers. It simply means its content is known to the domain and available for use. Deployments are only deployed on servers when they are mapped to server groups (see below).
h4. Server Groups
Besides the general configuration concepts described in the "General Configuration Concepts" section above, the most important element in the domain.xml is the definition of Server Groups. Each AS instance is a member of a server group. (Even if the group only has a single server, the server is still a member of a group.) It is the responsibility of the domain management system to ensure that all servers in a server group have a consistent configuration. They should all be configured with the same profile and they should have the same deployment content deployed.
The domain can have multiple server groups.
An example server group definition is as follows:
<server-group name="main-server-group" profile="default">
<socket-binding-group ref="standard-sockets"/>
<deployments>
<deployment name="foo.war_v1" runtime-name="foo.war" hash="ABCDEFG1234567890ABC"/>
<deployment name="bar.ear" runtime-name="bar.ear" hash="1234567890ABCDEFG123"/>
</deployments>
</server-group>
A server-group configuration includes the following required attributes:
* name -- the name of the server group
* profile -- the name of the profile the servers in the group should run
In addition, the following optional elements are available:
* socket-binding-group -- specifies the name of the default socket binding group to use on servers in the group. Can be overridden on a per-server basis in host.xml. If not provided in the server-group element, it must be provided for each server in host,xml.
* deployments -- the deployment content that should be deployed on the servers in the group.
* system-properties -- system properties that should be set on all servers in the group
* jvm -- default jvm settings for all servers in the group. The Host Controller will merge these settings with any provided in host.xml to derive the settings to use to launch the server's JVM. See the "JVMs" section in "Host.xml Configuration Concepts" below.
h3. Host.xml Configuration Concepts
h4.
Paths and Interfaces
Any paths or interfaces declared in domain.xml but not fully specified there need to be fully specified in host.xml. Since filesystem paths and IP addresses often vary from host to host, these details are often provided in eac host's host.xml.
h4. System Properties
System property values can be declared in a top level element in host.xml. Properties declared here will be set on all servers launched on the host.
h4. JVMs
The host.xml file can include one or more named JVM configurations. The configurations will include such details as the location of the JVM binary, heap sizes, environment variables, etc. The individual server configurations can refer to one of these JVM configurations by name and the Host Controller will use the named configuration to launch the server.
Note that JVM configuration details can also come from the server-group element in domain.xml and from the individual server element (see below.) If configured in more than one place, the elements will be merged, with server element values taking priority over server-group values, which in turn take priority over the host-level jvm configuration.
h4. Management Interfaces
The configuration of the connectors the Host Controller exposes to support remote management. TODO details
h4. Domain Controller
Configuration of how the Host Controller should find and communicate with the Domain Controller:
<domain-controller>
<!-- Remote domain controller configuration with a host and port -->
<remote host="192.168.100.1" port="9999"/>
</domain-controller>
TODO details
If this host should act as Domain Controller, this is declared as follows:
<domain-controller>
<local/>
</domain-controller>
h4.
h4. Servers
The most significant configuration item in host.xml is the listing of the servers that should be launched on the host. Each server has its own element:
<servers>
<server name="server-one" group="main-server-group">
<!-- server-one inherits the default socket-group declared in the server-group -->
<jvm name="default" />
</server>
<server name="server-two" group="main-server-group" start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-binding-group ref="standard-sockets" port-offset="150"/>
<jvm name="default">
<heap size="64m" max-size="256m"/>
</jvm>
</server>
<server name="server-three" group="other-server-group" start="false">
<!-- server-three avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-binding-group ref="standard-sockets" port-offset="250"/>
</server>
</servers>
Each server element includes the following required attributes:
* name -- the name of the server. Must be unique across the host.
* group -- the name of the server-group the server is a member of
* start -- (defaults to true) whether the server should be automatically started when the Host Controller starts
In addition, the server element includes the following optional elements:
* socket-binding-group -- the name of the socket binding group to use. Besides the socket binding group name, a port-offset can also be configured. The value of this attribute will be added to the port attribute value for any binding to derive the actual port to use for the socket. Setting the port-offset to a value other than zero allows multiple AS instances with the same socket binding and interface configurations to run on the same machine without having port conflicts.
* paths -- allows specification of paths at the individual server level. Configurations at this level will override any configurations with the same name at the domain or host level.
* interface-specs -- allows specification of interfaces at the individual server level. Configurations at this level will override any configurations with the same name at the domain or host level.
* system-properties -- system properties values specific to this server
* jvm -- jvm configurations for this server
h2.
Available Subsystems
AS 7 is under active development. Not all capabilities present in more mature releases of the AS 5 and 6 series are available in AS 7 yet. Following is a brief listing of the subsystems available in the various AS 7 releases. Items listed below may not be entirely feature complete.
h4. 7.0.0.Beta1
* logging -- configuration of logging appenders, categories, etc
* threads -- thread pool management
* sockets -- socket binding management
* naming -- local JNDI. Note that direct remote access to JNDI is not supported in Alpha1 (see the client.jms demo for an example of a clever hack to get remote access to JNDI via an MBeanServerConnection)
* transactions -- JTA
* jmx -- MBeanServer with remote access capability
* web -- basic servlet and JSP support
* ee - common EE facilities (injection etc)
* ejb3 - EJB3 component implementaton
* jax-rs - RestEasy integration
* messaging -- HornetQ server
* JMS -- JMS queues, topics and connection factories
* JCA connectors
* Datasources
* JCA resource adapter deployments
* osgi -- OSGI bundle deployment
* remoting -- JBoss Remoting 3 connectors
* managed beans -- EE 6 managed bean deployments
* SAR deployments -- both legacy mbean deployments and those based on the JDK 6 ServiceLoader concept. Note that not all legacy sar capabilities are supported
* Filesystem based hot deployment scanning (standalone mode only) -- note that exploded deployments are not currently supported
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module from the /demos directory will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available host controller configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, host controller and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
[JBoss AS7 Development] - JBoss AS7 User Guide
by Matt Drees
Matt Drees [http://community.jboss.org/people/matt.drees] modified the document:
"JBoss AS7 User Guide"
To view the document, visit: http://community.jboss.org/docs/DOC-16068
--------------------------------------------------------------
This is a brief guide intended to help users who wish to experiment with JBoss AS 7 as it undergoes development. Feedback on its content is most appreciated, either via comments on this page, via forum posts in this "JBoss AS7 Development" section of the wiki, or by posts to the https://lists.jboss.org/mailman/listinfo/jboss-development jboss-development mailing list.
AS 7 is currently in "Beta" status, so users should not expect all of the capabilities of more stable AS 5 and 6 releases to be present. Users should also be aware that significant changes may be made from one alpha release to another.
In addition to this, please reference http://community.jboss.org/en/jbossas/dev/jboss_as7_development?view=tags... all articles tagged #jboss_7_userguide
h2. Getting JBoss AS 7
AS 7 is available from the http://www.jboss.org/jbossas/downloads.html jboss.org download page. As in earlier JBoss AS releases, installation consists of unzipping the release distribution.
Users are encouraged to check out the AS 7 source and build it themselves. This is quite quick and painless once git is installed on your system, and getting git set up is also quite easy to do. See the http://community.jboss.org/docs/DOC-15596 Hacking On JBoss AS 7 wiki page for more details on working with the AS 7 source.
h2. Quick Start
Once you have the distribution unzipped, you need to decide whether you want to work in "domain mode" or "standalone mode". See "Domain Mode vs. Standalone Mode" below for more on what those choices mean.
If you want to work in domain mode, open a terminal and cd into the distribution's bin directory, and run the "domain" launch script:
$ cd bin
$ ./domain.sh
On Windows:
> cd bin
> domain.bat
This will launch a total of 5 processes on your system: three JBoss AS server instances; a Domain Controller process that acts as a central management point for all servers that belong to the same "domain"; and a lightweight Process Controller process that is responsible for spawning the other 4 processes and monitoring their lifecycle.
If you want to work in standalone mode, open a terminal and cd into the distribution's bin directory, and run the "standalone" launch script:
$ cd bin
$ ./standalone.sh
On Windows:
> cd bin
> standalone.bat
This will launch a single process on your system, a standalone JBoss AS server instance.
If you have the AS 7 source checked out, there are a number of demos that can be run from the source checkout's demos module. See below for details.
h2. Domain Mode vs. Standalone Mode
One of the primary new features of AS 7 is the ability to manage multiple AS instances from a single control point. A collection of such servers are referred to as members of a "domain", with a single Domain Controller process acting as the management control point. Domains can span multiple physical (or virtual) machines, with all AS instances on a given host under the control of a Host Controller process. The Host Controllers interact with the Domain Controller to control the lifecycle of the AS instances running on that host and to assist the Domain Controller in managing them.
When you launch JBoss AS in "domain mode" (via the domain.sh or domain.bat launch scripts) your intent is to launch a Domain Controller, a Host Controller and usually at least one AS instance.
For more on running servers in domain mode, a roughly 20 minute video is available online (divided in two pieces):
http://www.youtube.com/watch?v=phV3QiKQf2E http://www.youtube.com/watch?v=phV3QiKQf2E
http://www.youtube.com/watch?v=gCeQ2KIO0qc http://www.youtube.com/watch?v=gCeQ2KIO0qc
For many use cases, the centralized managment capability available via domain mode is not necessary. For these use cases, the AS can also be run in "standalone mode". In standalone mode each AS instance is an independent process, much like an AS 3, 4, 5, or 6 instance is. Standalone instances can be launched via the standalone.sh or standalone.bat launch scripts.
If more than one standalone instance is launched and multi-server management is desired, it is the user's responsibility to coordinate management across the servers.
A given server instance cannot be switched between domain mode and standalone mode; i.e. you cannot launch domain.sh, stop the processes, and then launch standalone.sh and expect any relationship between what was running. The configurations are separate. We may in future releases include some tooling to ease the task of translating a given server configuration from domain mode to standalone mode.
h4. Deciding Between Domain Mode and Standalone Mode
Which use cases are appropriate for domain mode and which are appropriate for standalone mode? Domain mode is all about coordinated multi-server management -- with it JBoss AS provides a central point through which users can manage multiple servers, with rich capabilities to keep those servers' configurations consistent and the ability to roll out configuration changes (including deployments) to the servers in a coordinated fashion.
It's important to understand that domain mode and standalone mode are all about how your servers are managed, not what capabilities they have to service end user requests. This distinction is particularly important when it comes to high availability clusters. The current AS 7 beta1 release does not support HA functionality. However, it's important to understand that once HA functionality is added in a later beta, it will be orthogonal to "domain mode" vs. "standalone mode". That is, a group of servers running in standalone mode will be able to be configured to form an HA cluster. The domain and standalone modes determine how the servers are managed, not what capabilities they provide.
So, given all that:
* A single server installation gains nothing from domain mode, so standalone mode is a better choice.
* For multi-server production environments, the choice of domain mode versus standalone mode comes down to whether the user wants to use the centralized management capability domain mode provides. Some enterprises have developed their own sophisticated multi-server management capabilities and are comfortable coordinating changes across a number of independent JBoss AS instances. For these enterprises, a multi-server architecture comprised of individual standalone mode AS instances is a good option.
* Standalone mode is better suited for most development scenarios. In particular, there is no "domain mode" for embedding JBoss AS; e.g. in an Arquillian-based testsuite. Any individual server configuration that can be achieved in domain mode can also be achieved in standalone mode, so even if the application being developed will eventually run in production on a domain mode installation, much (probably most) development can be done using standalone mode.
* Domain mode can be helpful in some advanced development scenarios; i.e. those involving interaction between multiple AS instances. Developers may find that setting up various servers as members of a domain is an efficient way to launch a multi-server cluster.
h2. Contents of the AS 7 Distribution
The AS 7 distribution includes the following directories:
*bin* -- location of the launch scripts
*docs* -- license files, documentation, schemas, examples, etc. The amount of content in this directory will increase as development continues.
*modules* -- AS 7 is based on a modular classloading architecture. The various modules used in the server are stored here. Generally speaking, this is not an area that would be modified by end users.
*domain* -- only relevant when domain mode is used. Configuration files, deployment content, and writeable areas used by the domain mode processes that run off of this installation. See below for further details.
*standalone* -- only relevant when standalone mode is used. Configuration files, deployment content, and writeable areas used by the single standalone server that runs off this installation. See below for further details.
h3. Contents of the "domain" Directory
Only relevant when domain mode is used.
*configuration* -- configuration files for the domain and for the Host Controller and any servers running off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*content* -- an internal working area for the Host Controller that controls this installation. This is where it internally stores deployment content. This directory is not meant to be manipulated by end users.
*log* -- location where the Process Controller and Host Controller write their log files.
*servers* -- writeable area used by each AS instance. Each AS instance will have its own subdirectory, created when the server is first started. In each server's subdirectory there will be the following subdirectories:
data -- information written by the server that needs to survive a restart of the server
log -- the server's log files
tmp -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide. (Not used in Beta1, removed for Beta2.)
h3. Contents of the "standalone" Directory
Only relevant when standalone mode is used.
*configuration* -- configuration files for the standalone server that runs off of this installation. If we've done our jobs well, these configuration files are the only configuration files end users should need to touch (outside of deployment descriptors in their own application deployments). See below for more on these files.
*data* -- information written by the server that needs to survive a restart of the server
*deployments* -- an area where end user deployment content can be placed if automatic detection and deployment of that content into the server's runtime is desired. The server's management API exposes other means for installing deployment content, and use of that API in preference to the deployments directory is preferred. We realize however, that at this early stage in AS 7's development the tooling around the deployment API is in its infancy, so many users will utilize the deployments directory to deploy content. Note that "domain mode" does not support deploying content based on scanning a filesystem.
*log* -- the server's log files
*tmp* -- location for temporary files written by the server
*system-content* -- an internal working area. Storage for non-end-user deployments; i.e. deployments that the subsystems that comprise a running AS themselves deploy into the runtime as part of the service they provide. (Not used in Beta1, removed for Beta2.)
h2. "Domain Mode" Configuration Files
Located in the *domain/configuration* directory.
*domain.xml* -- primary configuration file for the domain. Among other things, includes the configuration of the various "profiles" that AS instances can be configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Includes the definition of groups of sockets that those subsystems may open. And includes definition of "server groups", to which a profile, a group of socket definitions and zero or more deployments are mapped. Each individual server will be mapped (in host.xml, see below) to a server group; the configuration of that server group largely defines the configuration of the individual server.
A domain.xml file must be located in the domain/configuration directory of an installation that's meant to run the Domain Controller. It does not need to be present in installations that are not meant to run a Domain Controller; i.e. those whose Host Controller is configured to contact a remote Domain Controller. The presence of a domain.xml file on such a server does no harm; it will be ignored.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <domain> element, to learn more about configuration of a Domain Controller.
*host.xml* -- configuration file for the Host Controller that runs off of this particular installation. Each installation must have a host.xml file. Contains configuration information that is specific to the particular installation. Primarily:
* the listing of the names of the actual AS server instances that are meant to run off of this installation, along with the server group they belong to.
* configuration of how the Host Controller is to contact the Domain Controller to register itself and access the domain configuration. This may either be configuration of how to find and contact a remote Domain Controller, or a configuration telling the Host Controller to itself act as the Domain Controller.
* configuration of items that are specific to the local physical installation. For example, named interface definitions declared in domain.xml can be mapped to an actual machine-specific IP address in host.xml. Abstract path names in domain.xml can be mapped to actual filesystem paths in host.xml.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <host> element, to learn more about configuration of a Host Controller.
*logging.properties* -- Contains the logging configuration for the Host Controller and Process Controller that run off of this installation. Also defines the initial bootstrap logging configuration for each individual AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the domain.xml file once the server boot has reached the point where that configuration is available.
h2. "Standalone Mode" Configuration Files
Located in the *standalone/configuration* directory.
*standalone.xml* -- primary configuration file for the AS instance. Among other things, includes the configuration of the "profile" that the AS instance is configured to run. A profile configuration includes the detailed configuration of the various subsystems that comprise that profile (e.g. an embedded JBoss Web instance is a subsystem; a JBoss TS transaction manager is a subsystem, etc). Also includes the definition of the sockets that those subsystems may open.
Users are encouraged to have a look at the https://github.com/jbossas/jboss-as/blob/master/controller/src/main/resou... AS 7 configuration schema, starting with the <server> element, to learn more about configuration of a standalone AS instance.
*logging.properties* -- Contains the initial bootstrap logging configuration for the AS instance. This boostrap logging configuration is replaced with the logging configuration specified in the standalone.xml file once the server boot has reached the point where that configuration is available.
h2. General Configuration Concepts
In both Domain Mode and Standalone Mode a number of common configuration concepts apply:
h4. Extensions
An extension is a module that extends the core capabilities of the server. The AS core is very simple and lightweight; most of the capabilities people associate with an application server are provided via extensions. An extension is packaged as a module in the modules folder. The user indicates that they want a particular extension to be available by including an <extension/> element naming its module in the domain.xml or standalone.xml file.
<extensions>
...
<extension module="org.jboss.as.transactions"/>
<extension module="org.jboss.as.web" />
<extension module="org.jboss.as.webservices" />
<extension module="org.jboss.as.weld" />
</extensions>
h4. Paths
A logical name for a filesystem path. The domain.xml, host.xml and standalone.xml configurations all include a section where paths can be declared. Other sections of the configuration can then reference those paths by their logical name, rather than having to include the full details of the path (which may vary on different machines). For example, the logging subsystem configuration includes a reference to the "jboss.server.log.dir" path that points to the server's "log" directory.
<file relative-to="jboss.server.log.dir" path="server.log"/>
The AS automatically provides a number of standard paths without any need for the user to configure them in a configuration file:
* jboss.home - the root directory of the JBoss AS distribution
* user.home - user's home directory
* user.dir - user's current working directory
* java.home - java installation directory
* jboss.server.base.dir - root directory for an individual server instance
* jboss.server.data.dir - directory the server will use for persistent data file storage
* jboss.server.log.dir - directory the server will use for log file storage
* jboss.server.tmp.dir - directory the server will use for temporary file storage
* jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances (domain mode only)
Users can add their own paths or override all except the first 5 of the above by adding a <path/> element to their configuration file.
<path name="example" path="example" relative-to="jboss.server.data.dir"/>
See the XSD for details.
A <path/> element in a domain.xml need not include anything more than the name attribute; i.e. it need not include any information indicating what the actual filesystem path is:
<path name="x"/>
Such a configuration simply says, "There is a path named 'x' that other parts of the domain.xml configuration can reference. The actual filesystem location pointed to by 'x' is host-specific and will be specified in each machine's host.xml file." If this approach is used, there must be a path element in each machine's host.xml that specifies what the actual filesystem path is:
<path name="x" path="/var/x" />
h4. Interfaces
h4.
A logical name for a network interface/IP address/host name to which sockets can be bound. The domain.xml, host.xml and standalone.xml configurations all include a section where interfaces can be declared. Other sections of the configuration can then reference those interfaces by their logical name, rather than having to include the full details of the interface (which may vary on different machines).
An interface configuration includes the logical name of the interface as well as information specifying the criteria to use for resolving the actual physical address to use. The criteria is one of two types: either a single element indicating that the interface should be bound to a wildcard address, or a set of one or more characteristics that an interface or address must have in order to be a valid match.
<interface name="global">
<!-- Use the wildcard address -->
<any-address/>
</interface>
<interface name="external">
<nic name="eth0"/>
</interface>
<interface name="default">
<!-- Match any interface/address on the right subnet if it's
up, supports multicast and isn't point-to-point -->
<subnet-match value="192.168.0.0/16"/>
<up/>
<multicast/>
<not>
<point-to-point/>
</not>
</interface>
<interface name="loopback">
<inet-address value="127.0.0.1"/>
</interface>
See the XSD for full details on the various criteria options.
An <interface/> element in a domain.xml need not include anything more than the name attribute; i.e. it need not include any information indicating what the actual IP address associated with the name is:
<interface name="internal"/>
Such a configuration simply says, "There is an interface named 'internal' that other parts of the domain.xml configuration can reference. The actual IP address pointed to by 'internal' is host-specific and will be specified in each machine's host.xml file." If this approach is used, there must be an interface element in each machine's host.xml that specifies the criteria for determining the IP address:
<interface name="internal">
<nic name="eth1"/>
</interface>
h4. Socket Bindings and Socket Binding Groups
A socket binding is a named configuration for a socket.
The domain.xml and standalone.xml configurations both include a section where named socket configurations can be declared. Other sections of the configuration can then reference those sockets by their logical name, rather than having to include the full details of the socket configuration (which may vary on different machines).
A socket binding includes the following information:
* name -- logical name of the socket configuration that should be used elsewhere in the configuration
* port -- base port to which a socket based on this configuration should be bound. (Note that servers can be configured to override this base value by applying an increment or decrement to all port values. See below for more details.)
* interface (optional) -- logical name (see "Interfaces" above) of the interface to which a socket based on this configuration should be bound
* multicast-address (optional) -- if the socket will be used for multicast, the multicast address to use
* multicast-port (optional) -- if the socket will be used for multicast, the multicast port to use
* fixed-port (optional, defaults to false) -- if true, declares that the value of port should always be used for the socket and should not be overridden
Socket binding configurations are organized inside a <socket-binding-group/> element. That element also includes a default-interface attribute; that interface will be used for any bindings that do not specify their interface attribute.
h4. System Properties
System property values can be set in a number of places in
domain.xml, host.xml and standalone.xml. The values in standalone.xml are set as part of the server boot process. Values in domain.xml and host.xml are applied to servers when they are launched.
h4. Profiles and Subsystems
The most significant part of the configuration in domain.xml and standalone.xml is the configuration of one (in standalone.xml) or more (in domain.xml) "profiles". A profile is a named set of subsystem configurations. A subsystem is an added set of capabilities added to the core server by an extension (see "Extensions" above). A subsystem provides servlet handling capabilities; a subsystem provides an EJB container; a subsystem provides JTA, etc. A profile is a named list of subsystems, along with the details of each subsystem's configuration. A profile with a large number of subsystems results in a server with a large set of capabilities. A profile with a small, focused set of subsystems will have fewer capabilities but a smaller footprint.
The content of an individual profile configuration looks largely the same in domain.xml and standalone.xml. The only difference is standalone.xml is only allowed to have a single profile element (the profile the server will run), while domain.xml can have many profiles, each of which can be mapped to one or more groups of servers. The profile element in domain.xml also supports an <includes profile="another_profile"/> tag which allows configuration reuse whereby several more complex profiles can include the contents of simpler profiles.
The contents of individual subsystem configurations look exactly the same between domain.xml and standalone.xml.
h2. Standalone Mode Configuration Concepts
In addition to the general configuration concepts described above, the following concepts are specific to an AS instance running in standalone mode.
h4. Server Name
The root <server/> element in standalone.xml include a name attribute. If set, the value becomes the name of the server. If not set
If not set, defaults to the runtime value of java.net.InetAddress.getLocalHost().getHostName(). Users are encouraged to use distinct names for all servers in the operational environment. The server name is made available to all services running in the server.
h4. Paths and Interfaces
As mentioned above, domain.xml supports not fully describing a path (by providing the actual filesystem path) or an interface (by providing criteria to determine the IP address to use). This is not supported in standalone.xml.
h4. Socket Binding and Avoiding Port Conflicts
In standalone.xml, only a single <socket-binding-group/> element is allowed.
In standalone.xml, the <socket-binding-group/> element can also include a port-offset attribute. The value of this attribute will be added to the port attribute value for any binding to derive the actual port to use for the socket. Setting the port-offset to a value other than zero allows multiple AS instances with the same socket binding and interface configurations to run on the same machine without having port conflicts.
In domain.xml the <socket-binding-group/> element does not include a port-offset attribute; see "Domain Mode Configuration Concepts" below for more on how an equivalent configuration is done.
h4. Profiles
As noted above, only a single profile element is allowed in standalone.xml.
h4. Deployments
The standalone.xml file includes a section listing the deployment content available for use on the server. Deployment content is made available for use either by uploading it using the AS's management APIs, or by configuring a deployment scanner service and placing the content in the folder scanned by that service (i.e. the deployments/ folder.)
Each deployment element includes the following information:
* name -- Unique identifier of the deployment. Must be unique across all deployments.
* runtime-name -- name by which the deployment should be known within the runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as name, but in some cases users may wish to have two deployments with the same runtime-name may (e.g. two versions of "foo.war") both available in the deployment content repository, in which case the deployments would need to have distinct name values but would have the same runtime-name
* hash -- a hash of the deployment content, created by the server when the content was uploaded. The server uses the hash internally to find content in the repository.
* start -- a boolean flag indicating whether the content is actually deployed into the runtime (and should be automatically deployed when the server starts.)
h2. Domain Mode Configuration Concepts
In addition to the general configuration concepts described above, the following concepts are specific to configuring a set of JBoss AS instances in domain mode.
h4. Domain.xml vs Host.xml
Domain configuration is divided into two portions: a set of configuration elements that is consistent on all hosts across the domain (stored in the domain.xml file on the host that is acting as the Domain Controller), and a set of configuration elements that differs on each host (stored in a host.xml on each host). Most configuration should come from the domain.xml; the host.xml is meant to be limited to details that need to vary from one host to another (e.g. IP addresses, filesystem paths, and, most significantly the names of the servers that should run on each host.
Each host's Host Controller is responsible for launching the servers configured in its host.xml file. To do this the Host Controller gets a copy of the domain-wide configuration from the Domain Controller, extracts the portion of the domain-wide configuration that is relevant to the server (e.g. the details of the profile the server is configured to run), applies host-specific information (e.g. the IP addresses to use for named interfaces), and creates a server-specific configuration. The Host Controller then launches the server process and provides it its configuration. If that server-specific configuration were represented in XML form, it would look the same as a standalone.xml file -- the Host Controller essentially synthesizes a standalone.xml from the relevant domain.xml and host.xml content.
h3. Domain.xml Configuration Concepts
h4. Profiles
As noted above, the domain.xml file can contain multiple profiles. Different servers in the domain can run different profiles.
h4. Paths and Interfaces
As discussed above, path and interface elements in domain.xml can legally include nothing more than the name of the path or interface, in which case each host.xml is responsible for specifying the details of the path or interface.
h4. Deployments
The Domain Controller maintains a repository of deployment content that is available for use in the servers in the domain.
The domain.xml file includes a section listing the deployment content available for use in the domain. Deployment content is made available for use by uploading it using the AS's management APIs.
Each deployment element includes the following information:
* name -- Unique identifier of the deployment. Must be unique across all deployments in the domain.
* runtime-name -- name by which the deployment should be known within the runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as name, but in some cases users may wish to have two deployments with the same runtime-name may (e.g. two versions of "foo.war") both available in the deployment content repository, in which case the deployments would need to have distinct name values but would have the same runtime-name
* hash -- a hash of the deployment content, created by the server when the content was uploaded. The server uses the hash internally to find content in the repository.
Note that the fact that a deployment is listed in the domain-level deployments listing does not mean it will actually be deployed on any servers. It simply means its content is known to the domain and available for use. Deployments are only deployed on servers when they are mapped to server groups (see below).
h4. Server Groups
Besides the general configuration concepts described in the "General Configuration Concepts" section above, the most important element in the domain.xml is the definition of Server Groups. Each AS instance is a member of a server group. (Even if the group only has a single server, the server is still a member of a group.) It is the responsibility of the domain management system to ensure that all servers in a server group have a consistent configuration. They should all be configured with the same profile and they should have the same deployment content deployed.
The domain can have multiple server groups.
An example server group definition is as follows:
<server-group name="main-server-group" profile="default">
<socket-binding-group ref="standard-sockets"/>
<deployments>
<deployment name="foo.war_v1" runtime-name="foo.war" hash="ABCDEFG1234567890ABC"/>
<deployment name="bar.ear" runtime-name="bar.ear" hash="1234567890ABCDEFG123"/>
</deployments>
</server-group>
A server-group configuration includes the following required attributes:
* name -- the name of the server group
* profile -- the name of the profile the servers in the group should run
In addition, the following optional elements are available:
* socket-binding-group -- specifies the name of the default socket binding group to use on servers in the group. Can be overridden on a per-server basis in host.xml. If not provided in the server-group element, it must be provided for each server in host,xml.
* deployments -- the deployment content that should be deployed on the servers in the group.
* system-properties -- system properties that should be set on all servers in the group
* jvm -- default jvm settings for all servers in the group. The Host Controller will merge these settings with any provided in host.xml to derive the settings to use to launch the server's JVM. See the "JVMs" section in "Host.xml Configuration Concepts" below.
h3. Host.xml Configuration Concepts
h4.
Paths and Interfaces
Any paths or interfaces declared in domain.xml but not fully specified there need to be fully specified in host.xml. Since filesystem paths and IP addresses often vary from host to host, these details are often provided in eac host's host.xml.
h4. System Properties
System property values can be declared in a top level element in host.xml. Properties declared here will be set on all servers launched on the host.
h4. JVMs
The host.xml file can include one or more named JVM configurations. The configurations will include such details as the location of the JVM binary, heap sizes, environment variables, etc. The individual server configurations can refer to one of these JVM configurations by name and the Host Controller will use the named configuration to launch the server.
Note that JVM configuration details can also come from the server-group element in domain.xml and from the individual server element (see below.) If configured in more than one place, the elements will be merged, with server element values taking priority over server-group values, which in turn take priority over the host-level jvm configuration.
h4. Management Interfaces
The configuration of the connectors the Host Controller exposes to support remote management. TODO details
h4. Domain Controller
Configuration of how the Host Controller should find and communicate with the Domain Controller:
<domain-controller>
<!-- Remote domain controller configuration with a host and port -->
<remote host="192.168.100.1" port="9999"/>
</domain-controller>
TODO details
If this host should act as Domain Controller, this is declared as follows:
<domain-controller>
<local/>
</domain-controller>
h4.
h4. Servers
The most significant configuration item in host.xml is the listing of the servers that should be launched on the host. Each server has its own element:
<servers>
<server name="server-one" group="main-server-group">
<!-- server-one inherits the default socket-group declared in the server-group -->
<jvm name="default" />
</server>
<server name="server-two" group="main-server-group" start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-binding-group ref="standard-sockets" port-offset="150"/>
<jvm name="default">
<heap size="64m" max-size="256m"/>
</jvm>
</server>
<server name="server-three" group="other-server-group" start="false">
<!-- server-three avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-binding-group ref="standard-sockets" port-offset="250"/>
</server>
</servers>
Each server element includes the following required attributes:
* name -- the name of the server. Must be unique across the host.
* group -- the name of the server-group the server is a member of
* start -- (defaults to true) whether the server should be automatically started when the Host Controller starts
In addition, the server element includes the following optional elements:
* socket-binding-group -- the name of the socket binding group to use. Besides the socket binding group name, a port-offset can also be configured. The value of this attribute will be added to the port attribute value for any binding to derive the actual port to use for the socket. Setting the port-offset to a value other than zero allows multiple AS instances with the same socket binding and interface configurations to run on the same machine without having port conflicts.
* paths -- allows specification of paths at the individual server level. Configurations at this level will override any configurations with the same name at the domain or host level.
* interface-specs -- allows specification of interfaces at the individual server level. Configurations at this level will override any configurations with the same name at the domain or host level.
* system-properties -- system properties values specific to this server
* jvm -- jvm configurations for this server
h2.
Available Subsystems
AS 7 is under active development. Not all capabilities present in more mature releases of the AS 5 and 6 series are available in AS 7 yet. Following is a brief listing of the subsystems available in the various AS 7 releases. Items listed below may not be entirely feature complete.
h4. 7.0.0.Beta1
* logging -- configuration of logging appenders, categories, etc
* threads -- thread pool management
* sockets -- socket binding management
* naming -- local JNDI. Note that direct remote access to JNDI is not supported in Alpha1 (see the client.jms demo for an example of a clever hack to get remote access to JNDI via an MBeanServerConnection)
* transactions -- JTA
* jmx -- MBeanServer with remote access capability
* web -- basic servlet and JSP support
* ee - common EE facilities (injection etc)
* ejb3 - EJB3 component implementaton
* jax-rs - RestEasy integration
* messaging -- HornetQ server
* JMS -- JMS queues, topics and connection factories
* JCA connectors
* Datasources
* JCA resource adapter deployments
* osgi -- OSGI bundle deployment
* remoting -- JBoss Remoting 3 connectors
* managed beans -- EE 6 managed bean deployments
* SAR deployments -- both legacy mbean deployments and those based on the JDK 6 ServiceLoader concept. Note that not all legacy sar capabilities are supported
* Filesystem based hot deployment scanning (standalone mode only) -- note that exploded deployments are not currently supported
h2. Demos in the Source Checkout
The source checkout includes a "demos" module that includes a number of demos that can be run from maven. Building the module from the /demos directory will output a usage note that explains how to run the demos:
usage:
[echo] To run an example:
[echo] 1) In a separate console window,start either a standalone JBoss AS instance or a JBoss AS domain
[echo] 2) Run mvn package -Dexample=<example.name> where "exammple.name is the name of the example
[echo]
[echo] Valid example names to run against a standalone JBoss AS instance are
[echo] sar - deploys mbeans packaged in a sar
[echo] managedbean - deploys a managed bean
[echo] serviceloader - deploys a serviceloader style service
[echo] messaging - deploys HornetQ native sender and receiver
[echo] jms - deploys HornetQ JMS sender and receiver
[echo] jms.client - Uses HornetQ JMS API from the client
[echo] rar - deploys a resource adapter
[echo] ds - deploys a test bean for data sources
[echo] war - deploys a simple servlet and connects to it
[echo] client.messaging - creates a HornetQ core queue using the management API
[echo] client.jms - creates a JMS queue using the management API
[echo] web.connector - creates and removes a jboss web connector
[echo]
[echo] Valid example names to run against a JBoss AS domain are
[echo] domain.configs - reads the domain config and any available host controller configs
[echo] domain.ds - deploys deploys a test bean for data sources
[echo] domain.messaging - deploys HornetQ native sender and receiver
[echo] domain.rar - deploys deploys a resource adapter
[echo] domain.servers - shows domain, host controller and server configs, starts/stops servers
The primary point of the demos is to look at the source code and see how they use the AS's management API to deploy content and/or alter the configuration of the running server(s). To see how an example works, look at the relevant demos/src/main/java/org/jboss/as/demos/<example.name>/runner.ExampleRunner.java file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16068]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0
[IronJacamar Development] - IronJacamar Management
by Jesper Pedersen
Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] modified the document:
"IronJacamar Management"
To view the document, visit: http://community.jboss.org/docs/DOC-16674
--------------------------------------------------------------
h1. IronJacamar management
The goal of this page is to describe the management features of the IronJacamar container, the design and key implementation classes.
*
#IronJacamar_management IronJacamar management
**
#Requirements Requirements
**
#Design Design
***
#ManagementRepository ManagementRepository
***
#Connector Connector
***
#Resource_Adapter Resource Adapter
***
#Connection_Factory Connection Factory
***
#ManagedConnectionFactory ManagedConnectionFactory
***
#AdminObject AdminObject
***
#ConfigProperty ConfigProperty
***
#DataSource DataSource
**
#Features Features
***
#Operations Operations
****
#PoolConfiguration PoolConfiguration
***
#Statistics Statistics
**
#Implementation Implementation
***
#Operations_687184 Operations
****
#PoolConfiguration_487622 PoolConfiguration
***
#Statistics_305663 Statistics
****
#PoolStatistics PoolStatistics
**
#Test_suite Test suite
**
#JDBC JDBC
**
#Related Related
h2. Requirements
The overall requirements are
* Show the configuration of deployed resource adapters and datasources
* Show statistics for resource adapters and datasources
* Apply changes to the configuration of deployed resource adapters and datasources
* Invoke operations on the deployed resource adapters and datasources
h2. Design
We should a central place where the management view of resource adapters and datasources are registered (ManagementRepository).
This repository provides access to classes (Connector / DataSource) that represent a single deployment of either a resource adapter or a datasource.
Each of these classes are split into a hierarchy where information about the deployment and references to the live objects are maintained. It must be a design goal that the management classes uses methods from the public API of the IronJacamar container.
ManagementRepository
|
|- Connector
| |
| |- Resource Adapter
| |
| |- Connection Factories
| |
| |- Admin Objects
|
|- DataSource
See a description of each class below.
The implementation must be pure POJO, and only depend on the IronJacamar container.
Clients of the management repository contains the management specific technology, such as
* Java Management Extensions (JMX)
* JBoss Application Server 7 domain model
* RHQ
That way we can provide an API that can be used from all client types.
h3. ManagementRepository
|| *Method
* || *Description* ||
| getConnectors() | The active resource adapters |
| getDataSources() | The active datasources |
h3. Connector
|| *Method
* || *Description* ||
| getUniqueId() | The unique identifier for the deployment |
| getResourceAdapter() | The resource adapter |
| getConnectionFactories() | The connection factories |
| getAdminObjects() | The admin objects |
h3. Resource Adapter
|| *Method
* || *Description
* ||
| getResourceAdapter() | A reference to the live object |
| getConfigProperties() | The config-property's for the resource adapter |
| getStatistics() | A reference to the statistics module for the resource adapter |
h3. Connection Factory
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name of the connection factory |
| getConnectionFactory() | A reference to the connection factory |
| getManagedConnectionFactory() | A reference to the managed connection factory |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h3. ManagedConnectionFactory
|| *Method
* || *Description* ||
| getManagedConnectionFactory() | A reference to the live object |
| getConfigProperties() | The config-property's for the managed connection factory |
| getStatistics() | A reference to the statistics module for the managed connection factory |
h3. AdminObject
|| *Method
* || *Description
* ||
| getJndiName() | The JNDI name for the admin object |
| getAdminObject() | A reference to the live object |
| getConfigProperties() | The config-property's for the admin object |
| getStatistics() | A reference to the statistics module for the admin object |
h3. ConfigProperty
|| *Method
* || *Description
* ||
| getName() | The name of the config-property |
| isDynamic() | Is the config-property dynamic - e.g. supports live updates |
| isConfidential() | Is the config-property confidential |
h3. DataSource
|| *Method
* || *Description* ||
| getJndiName() | The JNDI name of the datasource |
| isXA() | Is the datasource XA capable |
| getPool() | A reference to the pool |
| getPoolConfiguration() | A reference to the pool configuration |
h2. Features
TBD
h3. Operations
Description of the operations that can be invoked are listed below.
* "Per request" -- Once an update has been performed it will be used at the next invocation of a method which uses the property in question
* "Per container" -- Is applied once a container is started/restarted
h4. PoolConfiguration
|| *Property
* || *Read* || *Write* || *Applied* ||
| MinSize | Y | Y | Per request |
| MaxSize | Y | Y | Per request |
| BlockingTimeout | Y | Y | Per request |
| IdleTimeout | Y | Y | Per container |
| BackgroundValidation | Y | Y | Per container |
| BackgroundValidationMinutes | Y | Y | Per container |
| Prefill | Y | Y | Per container |
| StrictMin | Y | Y | Per request |
| UseFastFail | Y | Y | Per request |
h3. Statistics
Statistics should be handled through an SPI using the following two interfaces
org.jboss.jca.core.spi.statistics.Statistics
org.jboss.jca.core.spi.statistics.StatisticsPlugin
The "Statistics" interface identifies that the component in question supports statistics. The "StatisticsPlugin" interface defines the contract for the statistics module.
h2. Implementation
The implementation is located in the core module of the IronJacamar repository. The package is
org.jboss.jca.core.api.management
The implementing classes must use java.lang.ref.WeakReference for all live object references, such that won't prevent a garbage collection of the object in question.
h3. Operations
h4. PoolConfiguration
Access can be done directly on the reference.
h3. Statistics
It is possible to enable/disable statistics collection, as well as clear current values.
All statistics are read-only.
h4. PoolStatistics
|| *Property
* || *Description* ||
| ActiveCount | The active count |
| AverageBlockingTime | The average time spent blocking on a connection |
| CreatedCount | The created count |
| DestroyedCount | The destroyed count |
| MaxWaitTime | The maximum time waiting for a connection |
| TimedOut | The timed out connections |
| TotalBlockingTime | The total time spent blocking for connections |
h2. Test suite
The management model is currently tested through the RHQ plugin.
h2. JDBC
The JDBC resource adapter has the following statistics exposed
|| *Statistics
* || *Description* ||
| PreparedStatementCacheAccessCount | The number of times that the statement cache was accessed |
| PreparedStatementCacheAddCount | The number of statements added to the statement cache |
| PreparedStatementCacheCurrentSize | The number of prepared and callable statements currently cached in the statement cache |
| PreparedStatementCacheDeleteCount | The number of statements discarded from the cache |
| PreparedStatementCacheHitCount | The number of times that statements from the cache were used |
| PreparedStatementCacheMissCount | The number of times that a statement request could not be satisfied with a statement from the cache |
h2. Related
* JBoss Application Server 7
* http://community.jboss.org/docs/DOC-16378 RHQ platform
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16674]
Create a new document in IronJacamar Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years
- 1
- 0