[jBPM Development] - How to integrate jbpm4.4 into jboss5.1.0.GA?
by frh10 ff
frh10 ff [http://community.jboss.org/people/frh10] created the discussion
"How to integrate jbpm4.4 into jboss5.1.0.GA?"
To view the discussion, visit: http://community.jboss.org/message/610972#610972
--------------------------------------------------------------
I install jbpm4.4 into jboss5 with the ant(build.xml):
<?xml version="1.0" encoding="UTF-8"?>
<!-- ====================================================================== -->
<!-- jBPM: Workflow in Java -->
<!-- -->
<!-- Distributable under LGPL license. -->
<!-- See terms of license at http://www.gnu.org http://www.gnu.org. -->
<!-- ====================================================================== -->
<!-- $Id: build.xml 6507 2010-07-18 06:00:34Z mailto:alex.guizar@jboss.com alex.guizar(a)jboss.com $ -->
<project name="jbpm.install">
<!-- DEVELOPER SPECIFIC CONFIGURATIONS -->
<property file="${user.home}/.jbpm4/build.properties" />
<!-- USER CUSTOMIZABLE PROPERTIES -->
<!-- {hsqldb | mysql | oracle | postgresql} -->
<property name="database" value="mysql" />
<!-- INTERNAL PROPERTY DEFAULTS -->
<condition property="jbpm.home" value="${jbpm.parent.dir}/jbpm-4.x" else="${basedir}/..">
<isset property="jbpm.parent.dir" />
</condition>
<property name="cfg.dest.dir" value="${jbpm.home}/install/generated/cfg" />
<property name="install.src.dir" value="${jbpm.home}/install/src" />
<property name="bind.address" value="localhost" />
<property name="jdbc.properties.dir" value="${jbpm.home}/install/jdbc" />
<property file="${jdbc.properties.dir}/${database}.properties" />
<property name="examples.file" value="${jbpm.home}/examples/target/examples.jar" />
<property name="tomcat.version" value="6.0.26" />
<property name="tomcat.parent.dir" value="${jbpm.home}" />
<property name="tomcat.home" value="${tomcat.parent.dir}/apache-tomcat-${tomcat.version}" />
<property name="tomcat.filename" value="apache-tomcat-${tomcat.version}.zip" />
<property name="tomcat.distro.dir" value="downloads" />
<property name="tomcat.distro.url"
value=" http://www.apache.org/dist/tomcat/tomcat-6/v${tomcat.version}/bin/${tomca... http://www.apache.org/dist/tomcat/tomcat-6/v${tomcat.version}/bin/${tomca..." />
<property name="tomcat.distro.path" value="${tomcat.distro.dir}/${tomcat.filename}" />
<property name="tomcat.lib.dir" value="${tomcat.home}/lib" />
<property name="tomcat.webapps.dir" value="${tomcat.home}/webapps" />
<property name="hsqldb.server.install.dir" value="${jbpm.home}/hsqldb-server" />
<property name="hsqldb.server.source.dir" value="${jbpm.home}/install/src/hsqldb-server" />
<property name="jboss.version" value="5.1.0.GA" />
<property name="jboss.parent.dir" value="${jbpm.home}" />
<property name="jboss.home" value="F:\jboss-5.1.0.GA" />
<property name="jboss.filename" value="jboss-${jboss.version}.zip" />
<property name="jboss.distro.dir" value="downloads" />
<property name="jboss.distro.url"
value=" http://downloads.sourceforge.net/jboss/${jboss.filename http://downloads.sourceforge.net/jboss/${jboss.filename}" />
<property name="jboss.distro.path" value="${jboss.distro.dir}/${jboss.filename}" />
<property name="jboss.server.configuration" value="all-with-hornetq" />
<property name="jboss.server.config.dir"
value="${jboss.home}/server/${jboss.server.configuration}" />
..................
the red parts are the modifications to fix my jboss and database,
but when i start the jboss,it throw a error:
2011-06-20 14:27:06,729 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=jboss.j2ee:module="jbpm-enterprise.jar",service=EjbModule state=Create mode=Manual requiredState=Installed
org.jboss.deployment.DeploymentException: Error in jbosscmp-jdbc.xml : datasource-mapping MS SQLSERVER2005 not found
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaData.<init>(JDBCEntityMetaData.java:517)
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCApplicationMetaData.<init>(JDBCApplicationMetaData.java:327)
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoader.load(JDBCXmlFileLoader.java:80)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDBCEntityMetaData(JDBCStoreManager.java:732)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(JDBCStoreManager.java:424)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:368)
at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
at org.jboss.ejb.EjbModule.startService(EjbModule.java:495)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189)
at $Proxy38.start(Unknown Source)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:619)
How can i solve this problem?Thanks!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/610972#610972]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 2
- 1
[jBPM Development] - How to Use Maven to distribute jBPM binaries?
by Ruben Fragoso
Ruben Fragoso [http://community.jboss.org/people/rnfragoso] created the discussion
"How to Use Maven to distribute jBPM binaries?"
To view the discussion, visit: http://community.jboss.org/message/628168#628168
--------------------------------------------------------------
Hello All
I am trying to understand how i can use Maven to distribute the binary of a jBPM Project. I have looked in the internet, and some formats appear like .BAR or .PAR but it is not clear which one is it, and how to create a maven project for it and how to use automatically deploy a binary into the jBPM/JBoss Server. Can anyone help me with it? Thank you in Advance
Best Regards
Ruben Fragoso
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/628168#628168]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 2
- 2
[jBPM Development] - taskform button action
by sunil deshpande
sunil deshpande [http://community.jboss.org/people/desunil] created the discussion
"taskform button action"
To view the discussion, visit: http://community.jboss.org/message/620571#620571
--------------------------------------------------------------
Hi all, I have a task node followed by a desicion node, in task node i have taskform where in i have 4 buttons, once the form is submitted , instance comes to desicion node, in decision node how i can get to know which button the user pressed in task activity... please help
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/620571#620571]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 4
- 5
[JBoss AS7 Development] - URL-Protocol Handler doesn't work
by Daniel Straub
Daniel Straub [http://community.jboss.org/people/dastraub] created the discussion
"URL-Protocol Handler doesn't work"
To view the discussion, visit: http://community.jboss.org/message/628372#628372
--------------------------------------------------------------
We register some protocol handler via the system property "java.protocol.handler.pkgs".
This works very well with JBoss 4.x and 5, but now in JBoss 7 the URL can't find our handler class (in java.net.URL.
getURLStreamHandler). Here the URL will load the handler with Class.forName, but the result is always null.
If we try to load the handler class in a EJB, it's work.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/628372#628372]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 4
- 7
[JBoss AS7 Development] - How do I put an MBean in JNDI?
by Matt Drees
Matt Drees [http://community.jboss.org/people/matt.drees] created the discussion
"How do I put an MBean in JNDI?"
To view the discussion, visit: http://community.jboss.org/message/606799#606799
--------------------------------------------------------------
Hi all,
I'm trying to get a SAR deployed to AS7.
One of my MBeans is trying to bind itself into JNDI using NonSerializableFactory.rebind(name, this, true). This apparently works fine on older jboss releases, but on AS7 I get this:
13:30:22,405 WARN [org.ccci.ha.HighAvailabilityDataSource] (MSC service thread 1-4) Starting up HighAvailabilityDataSource ccpDatasource in PRIMARY mode
13:30:22,406 INFO [stdout] (MSC service thread 1-4) fullName=jdbc/ccpDatasource
13:30:22,406 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.mbean.service."jboss.jca:name=jdbc/ccpDatasource,service=DataSourceBinding".start: org.jboss.msc.service.StartException in service jboss.mbean.service."jboss.jca:name=jdbc/ccpDatasource,service=DataSourceBinding".start: Failed to execute legacy service start() method
at org.jboss.as.service.StartStopService.start(StartStopService.java:51)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:59)
at org.jboss.as.service.StartStopService.start(StartStopService.java:49)
... 4 more
Caused by: java.lang.UnsupportedOperationException: Naming context is read-only
at org.jboss.as.naming.NamingContext.rebind(NamingContext.java:227)
at javax.naming.InitialContext.rebind(InitialContext.java:408) [:1.6.0_24]
at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:185)
at org.jboss.util.naming.NonSerializableFactory.rebind(NonSerializableFactory.java:250)
at org.ccci.ha.HighAvailabilityDataSource.rebind(HighAvailabilityDataSource.java:53)
at org.ccci.ha.HighAvailabilityDataSource.start(HighAvailabilityDataSource.java:34)
... 10 more
So, it looks like JNDI is read-only now. What is the recommended approach for making an MBean available in JNDI?
Or, perhaps I'm just going about this all the wrong way. What I really need is to make a custom javax.sql.Datasource available in JNDI, and I need to be able to do some logic on start-up. (I don't want to use JCA for this, since this datasource simply delegates to one of two other standard (JCA) datasources.) I'm sure I don't need this object to be an MBean, but that seemed the simplest thing at the time. Is there a better way to do this?
Thanks!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/606799#606799]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 5
- 7
[JBoss AS7 Development] - Data Source Configuration in AS 7
by sgilda
sgilda [http://community.jboss.org/people/sgilda] modified the document:
"Data Source Configuration in AS 7"
To view the document, visit: http://community.jboss.org/docs/DOC-16657
--------------------------------------------------------------
*
#Using_DataSourceDefinition_to_configure_a_DataSource Using @DataSourceDefinition to configure a DataSource
*
#Defining_a_Managed_DataSource Defining a Managed DataSource
**
#Installing_the_JDBC_Driver Installing the JDBC Driver
***
#Installing_a_JDBC_driver_as_a_deployment Installing a JDBC driver as a deployment
****
#Modify_the_JAR Modify the JAR
***
#Installing_a_JDBC_driver_as_a_module Installing a JDBC driver as a module
**
#Defining_the_DataSource_itself Defining the DataSource itself
*
#Links Links
In older versions of the application server, data source configuration was tied to a *-ds.xml file schema that you would deploy in the deploy directory of your configuration. In AS 7, the entire structure of the AS is different, and as you would expect, creating your own data sources is different as well.
h1. Using @DataSourceDefinition to configure a DataSource
Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.) This annotation requires that a data source implementation class (generally from a JDBC driver JAR) be present on the class path (either by including it in your application, or deploying it as a top-level JAR and referring to it via MANIFEST.MF's Class-Path attribute) and be named explicitly.
h1. Defining a Managed DataSource
In order for a data source to be managed by the application server (and thus take advantage of the management and connection pooling facilities it provides), you must perform two tasks. First, you must make the JDBC driver available to the application server; then you can configure the data source itself. Once you have performed these tasks you can use the data source via standard JNDI injection.
h2. Installing the JDBC Driver
The JDBC driver can be installed into the container in one of two ways: either as a deployment or as a core module. There are pros and cons to each approach, which will be outlined below.
h3. Installing a JDBC driver as a deployment
The recommended way to install a JDBC driver into the application server is to simply deploy it as a regular JAR deployment. The reason for this is that when you run your application server in domain mode, deployments are automatically propagated to all servers to which the deployment applies; thus distribution of the driver JAR is one less thing for administrators to worry about.
cp jdbc.jar <as7>/standalone/deployments
Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechaism. Such JARs will contain a text a file named "META-INF/services/java.sql.Driver", which contains the name of the class(es) of the Drivers which exist in that JAR.
If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways.
h4. Modify the JAR
The most straightforward solution is to simply modify the JAR and add the missing file. You can do this from your command shell by:
1. Change to, or create, an empty temporary directory.
2. Create a "META-INF" subdirectory.
3. Create a "META-INF/services" subdirectory.
4. Create a "META-INF/services/java.sql.Driver" file which contains one line - the fully-qualified class name of the JDBC driver.
5. Use the "jar" command-line tool to update the JAR like this:
jar -uf jdbc-driver.jar META-INF/services/java.sql.Driver
h3.
Please note that you need to correctly setup datasource's driver tag when installing the driver as a deployment (see below in the datasource configuration section).
h3. Installing a JDBC driver as a module
Under the root directory of the application server, is a directory called modules (e.g. jboss-7.0.0.<release>/modules). In this example, I will create the MySQL module in the same tree as the H2 database. The H2 database, which comes preconfigured, like the old DefaultDS with Hypersonic, is under the com/h2database/h2 directory, under the modules directory. So, the first step is to create a directory structure simlar to that for MySQL. I created, under com, a mysql directory, plus a main directory. So, at this point it should like like the following:
jboss-7.0.0.<release>/modules/com/mysql/main
Under the main directory, you need to define your module with a module.xml file, and the actual jar file that contains your database driver. In my case, the mysql-connector-java-5.1.15.jar file. This is in contrast to putting the database driver jar file in the old lib directory under your configuration where you deployed your *-ds.xml file. Also, the jar file must have a META-INF/services/java.sql.Driver file. This is due to the way AS 7 will load the driver. Fortunately, the MySQL JDBC driver jar file has this. So, what's the content of the module.xml file.
It's fairly straightforward, and is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ JBoss, Home of Professional Open Source.
~ Copyright 2010, Red Hat, Inc., and individual contributors
~ as indicated by the @author tags. See the copyright.txt file in the
~ distribution for a full listing of individual contributors.
~
~ This is free software; you can redistribute it and/or modify it
~ under the terms of the GNU Lesser General Public License as
~ published by the Free Software Foundation; either version 2.1 of
~ the License, or (at your option) any later version.
~
~ This software is distributed in the hope that it will be useful,
~ but WITHOUT ANY WARRANTY; without even the implied warranty of
~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
~ Lesser General Public License for more details.
~
~ You should have received a copy of the GNU Lesser General Public
~ License along with this software; if not, write to the Free
~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
~ 02110-1301 USA, or see the FSF site: http://www.fsf.org.
-->
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-5.1.15.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
</dependencies>
</module>
As you can see from above, we give the module name, which in this example is com.mysql, which matches the directory structure we had created under the modules directory.
Besides the module name, we need to tell it where the implementation is, which is the resource-root tag with the path element. In that path element, we simply put the jar name. The path appears to be relative, and default to the main directory under the directory structure you created, which of course is com/mysql in our case.
Finally, you define any dependencies you might have. In this case, as the case with all JDBC data sources, we would be dependent on the Java JDBC API's, which in this case in defined in another module called javax.api, which you can find under modules/javax/api/main as you would expect.
That's really all there is to creating the module, but it will not be started as a service by AS 7, unless its referenced in the configuration. Now, just like everything else in AS 7, configuration is now completely different. There are two main configurations.
h2. Defining the DataSource itself
The first configuration is called domain, and has a domain directory under the root directory of the AS 7 distribution. This is a configuration that is geared toward multiple server instances and multiple server installations. The second is standalone, which is geared for a single instance of the server running on a single server, as you would expect. In regards to data source configuration, there really is no difference, as the datasource schema definition is the same in both cases. So regardless of which one you may be using in your particular case, the configuration is the same. For reference you can see the data source information here:
http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.htm...
In either standalone.xml or domain.xml you add the reference to the MySQL module as follows:
<datasources>
<datasource jndi-name="java:jboss/datasources/MySqlDS" pool-name="MySqlDS">
<connection-url>jdbc:mysql://localhost:3306/EJB3</connection-url>
* <driver>**com.mysql**</driver>*
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>100</max-pool-size>
<prefill>true</prefill>
</pool>
<security>
<user-name>test</user-name>
<password>test</password>
</security>
<statement>
<prepared-statement-cache-size>32</prepared-statement-cache-size>
<share-prepared-statements/>
</statement>
</datasource>
<drivers>
<driver name="com.mysql" module="com.mysql">
<xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
The <datasources> tag can contain multiple datasource and XA datasource definitions.They are all included in the one configuration file, either standalone.xml or domain.xml depending on which you are using. In each case the directory structure is as follows:
jboss-7.0.0.<release>/domain/configuration/domain.xml or
jboss-7.0.0.<release>/standalone/configuration/standalone.xml
The other important things to point out, besides the standard JDBC parameters, is the *driver* tag above, and a new section called drivers which is within the "datasources" subsystem in the schema, but below the data sources themselves.
In the *driver* tag above, you should specify the unique name that you gave the driver definition in the *drivers* section.
In case you installed driver as a deployment, the *driver* tag in datasource definition should match the deployment file name.
As you can see, what we put in this is the actual module name we defined in module.xml under jboss-7.0.0.<release>/modules/com/mysql/main/module.xml.
That's all there is to it. The MySQL module is attached as an example.
h1. Links
* https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-DataSources
* http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.htm...
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16657]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 5 months
- 1
- 0
[JBoss Tools Development] - Re: No Persistence library in Hibernate Tools Eclipse Plugin?
by Max Rydahl Andersen
Max Rydahl Andersen [http://community.jboss.org/people/maxandersen] created the discussion
"Re: No Persistence library in Hibernate Tools Eclipse Plugin?"
To view the discussion, visit: http://community.jboss.org/message/628205#628205
--------------------------------------------------------------
Depends what version you want to use.
I suggest you start here: http://www.hibernate.org/quick-start http://www.hibernate.org/quick-start
and if you want the version that works best with hibernate tools plugin continue on to: http://docs.jboss.org/hibernate/core/3.5/reference/en-US/html/ http://docs.jboss.org/hibernate/core/3.5/reference/en-US/html/
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/628205#628205]
Start a new discussion in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 2
- 1
[JBoss Tools Development] - No Persistence library in Hibernate Tools Eclipse Plugin?
by mairr mairrr
mairr mairrr [http://community.jboss.org/people/mairr] created the discussion
"No Persistence library in Hibernate Tools Eclipse Plugin?"
To view the discussion, visit: http://community.jboss.org/message/628149#628149
--------------------------------------------------------------
Hello all,
I am new to Hibernate and need some help.
I am using Eclipse Indigo and Hibernate Tools Eclipse Plugin 3.4.
I've successfully setup hibernate configuration including database driver, connection url and selected the java project where hibernate will be used.
For mapping I want to use Annotation, so i could "mark" the fields, with attributes (@Entity, @id...).
To do this I must use imports:
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.GeneratedValue;
But those imports couldn't be resolved.
Shouldn't plugin take care of those jars??
How can I fix it?
THanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/628149#628149]
Start a new discussion in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
- 2
- 2
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Format of a Detyped Operation Request"
To view the document, visit: http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
See http://community.jboss.org/docs/DOC-16354 this page for a discussion of the format of the response.
See http://community.jboss.org/docs/DOC-16317 this page for a more in depth example of using the native management API.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = op.get("address");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the outermost elements appear in the request is not relevant. The required elements are:
* operation -- String -- The name of the operation being invoked.
* address -- the address of the managed resource against which the request should be executed. If not set, the address is the root resource. The address is an +ordered+ list of key-value pairs describing where the resource resides in the overall management resource tree. Management resources are organized in a tree, so the order in which elements in the address occur is important.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for operation, address and operation-headers.
h3. Operation Headers
Besides the special operation and address values discussed above, operation requests can also include special "header" values that help control how the operation executes. These headers are created under the special reserved word operation-headers:
ModelNode op = new ModelNode();
op.get("operation").set("write-core-threads");
ModelNode addr = op.get("address");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
op.get("operation-headers", "rollback-on-runtime-failure").set(false);
System.out.println(op);
This produces:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"operation-headers" => {
"rollback-on-runtime-failure => false
}
}
The following operation headers are supported:
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether an operation that successfully updates the persistent configuration model should be reverted if it fails to apply to the runtime. Operations that affect the persistent configuration are applied in two stages -- first to the configuration model and then to the actual running services. If there is an error applying to the configuration model the operation will be aborted with no configuration change and no change to running services will be attempted. However, operations are allowed to changed the configuration model even if there is a failure to apply the change to the running services -- if and only if this rollback-on-runtime-failure header is set to false. So, this header only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
* rollout-plan -- only relevant to requests made to a Domain Controller or Host Controller. See "Operations with a Rollout Plan" for details.
* allow-resource-service-restart -- boolean, optional, defaults to false. Whether an operation that requires restarting some runtime services in order to take effect should do so. See discussion of resource-services in the "Applying Updates to Runtime Services" section of the http://community.jboss.org/docs/DOC-16317 Detyped Description of the AS 7 Management Model wiki for further details.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as an atomic unit*. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
+* See the discussion below of the rollback-on-runtime-failure operation header for how the atomicity requirement can be relaxed.+
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"operation-headers" => {
"rollback-on-runtime-failure => false
}
}
The "composite" operation takes a single parameter:
* steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps. Note that the rollback-on-runtime-failure and rollout-plan operation headers are not supported for the individual steps in a composite operation.
The rollback-on-runtime-failure operation header discussed above has a particular meaning when applied to a composite operation, controlling whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed.
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"operation-headers" => {
"rollout-plan" => {
"in-series" => [
{
"concurrent-groups" => {
"groupA" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupB" => undefined
},
"server-group" => {
"groupC" => {
"rolling-to-servers" => false,
"max-failed-servers" => 1
}
}
},
{"server-group" => {"groupC" => undefined}},
{
"concurrent-groups" => {
"groupD" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupE" => undefined
}
}
]},
"rollback-across-groups" => true
}
}
}
As you can see, the rollout plan is another structure in the operation-headers section. The root node of the structure allows two children:
* in-series -- a list -- A list of steps that are to be performed in series, with each step reaching completion before the next step is executed. Each step involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
* rollback-across-groups -- boolean -- indicates whether the need to rollback the operation on all the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures:
* concurrent-groups -- a map of server group names to policies controlling how the operation should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
* server-group -- a single key/value mapping of a server group name to a policy controlling how the operation should be applied to that server group. See below for details on the policy configuration. +(Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)+
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
* rolling-to-servers -- boolean -- If true, the operation will be applied to each server in the group in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
* max-failed-servers -- int -- Maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
* max-failure-percentage -- int between 0 and 100 -- Maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
1. Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
2. Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
3. Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.
h3. Default Rollout Plan
All operations that impact multiple servers will be executed with a rollout plan. However, actually specifying the rollout plan in the operation request is not required. If no rollout-plan is specified, a default plan will be generated. The plan will have the following characteristics:
* There will only be a single high level phase. All server groups affected by the operation will have the operation applied concurrently.
* Within each server group, the operation will be applied to all servers concurrently.
* Failure on any server in a server group will cause rollback across the group.
* Failure of any server group will result in rollback of all other server groups.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 5 months
- 1
- 0
[JBoss AS7 Development] - Detyped Description of the AS 7 Management Model
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Detyped Description of the AS 7 Management Model"
To view the document, visit: http://community.jboss.org/docs/DOC-16317
--------------------------------------------------------------
AS 7's management API will naturally include the ability for clients to query the management system to discover meta-information about the management model; i.e. what resources are available and what attributes and operations they expose. These details will be returned in a detyped form, either using the https://github.com/jbossas/jboss-dmr jboss-dmr library or JSON. (A JMX interface based on open mbeans will also be provided; most concepts in this article map naturally to JMX.) The purpose of this article is to describe the detyped representation of the API.
Readers are encouraged to look at the example detyped descriptions of parts of the management API at the bottom before reading the details.
Before getting into the details of the meta-information, first a couple quick examples on how to access it.
h5. Reading Management Model Descriptions via the raw Management API
The client must have maven artifact org.jboss.as:jboss-as-controller-client and its dependencies on the classpath.
1) Create a management client that can connect to your target process's native management socket (which can be an individual standalone mode server, or, in a domain mode environment, the Domain Controller or any Host Controller:
ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("localhost"), 9999);
The address and port are what is configured in the target process' <management-apis><native-api.../> element.
2) Create an operation request object using the org.jboss.dmr.ModelNode class:
ModelNode op = new ModelNode();
op.get("operation").set("read-resource-description");
op.get("recursive").set(true);
op.get("operations").set(true);
ModelNode address = op.get("address");
address.add("subsystem", "web");
address.add("connector", "http");
See http://community.jboss.org/docs/DOC-16336 http://community.jboss.org/docs/DOC-16336 for basic background on the format of an operation request. The key thing here is we are executing the "read-resource-description" operation. That operation can be targetted at any address in the management model; here we are targetting it at the resource for the web subsystem's http connector.
The request includes two optional parameters:
* recursive -- true means you want the description of child resources under this resource. Default is false
* operations -- true means you want the description of operations exposed by the resource to be included. Default is false.
3) Execute the operation and manipulate the result:
ModelNode returnVal = client.execute(op);
System.out.println(returnVal.get("result").toString());
See http://community.jboss.org/docs/DOC-16354 http://community.jboss.org/docs/DOC-16354 for general details on the structure of the "returnVal" ModelNode.
h5. Reading Management Model Descriptions via the CLI
See http://community.jboss.org/docs/DOC-16581 http://community.jboss.org/docs/DOC-16581 for basics on using the CLI.
Once you've launched the CLI the syntax for the command shown above would be:
[localhost:9999 /] /subsystem=web/connector=http:read-resource-description(recursive=true,operations=true)
h3.
h3. Description of addressable portions of the management model
All portions of the management model exposed by AS 7 are addressable via an ordered list of key/value pairs. For each addressable portion of the model, the following descriptive information will be available:
* description -- String -- text description of this portion of the model
* head-comment-allowed -- boolean -- indicates whether this portion of the model can store an XML comment that would be written in the persistent form of the model (e.g. domain.xml) before the start of the XML element that represents this portion of the model. This item is optional, and if not present defaults to true. +*(Note: storing XML comments in the in-memory model is not currently supported and likely will not be supported in AS 7.1. This description key is for future use.)*+
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates whether a comment just before the close of the XML element is supported. A tail comment can only be supported if the element has child elements, in which case a comment can be inserted between the final child element and the element's closing tag. This item is optional, and if not present defaults to true. +*(Note: storing XML comments in the in-memory model is not currently supported and likely will not be supported in AS 7.1. This description key is for future use.)*+
* attributes -- Map of String (the attribute name) to complex structure -- the configuration attributes available in this portion of the model. See below for the representation of each attribute.
* operations -- Map of String (the operation name) to complex structure -- the operations that can be targetted at this address. See below for the representation of each operation.
* children -- Map of String (the type of child) to complex structure -- the relationship of this portion of the model to other addressable portions of the model. See below for the representation of each child relationship.
{
"description => "A managable resource",
"tail-comment-allowed" => false,
"attributes" => {
"foo" => {
.... details of attribute foo
}
},
"operations" => {
"start" => {
.... details of the start operation
}
},
"children" => {
"bar" => {
.... details of the relationship with children of type "bar"
}
}
}
h4. Description of an Attribute
An attribute is a portion of the management model that is not directly addressable. Instead, it is conceptually a property of an addressable part of the model. For each attribute portion of the model, the following descriptive information will be available:
* description -- String -- text description of the attribute
* type -- org.jboss.dmr.ModelType -- the type of the attribute value. One of the enum values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT, PROPERTY, STRING. Most of these are self-explanatory. An OBJECT will be represented in the detyped model as a map of string keys to values of some other legal type, conceptually similar to a javax.management.openmbean.CompositeData. A PROPERTY is a single key/value pair, where the key is a string, and the value is of some other legal type.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT. If type is LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
* expressions-allowed -- boolean -- indicates whether the value of the attribute may be of type ModelType.EXPRESSION, instead of its standard type (see type and value-type above for discussion of an attribute's standard type.) A value of ModelType.EXPRESSION contains a system-property substitution expression that the server will resolve against the +server-side+ system property map before using the value. For example, an attribute named max-threads may have an expression value of ${example.pool.max-threads:10} instead of just 10. Default value if not present is false.
* required -- boolean -- true if the attribute will always exist in a representation of its portion of the model; false if it may not (implying a null value.) If not present, true is the default.
* storage -- String -- Either "configuration" or "runtime". If "configuration" it means the attribute's value is stored as part of the persistent configuration (e.g. in domain.xml, host.xml or standalone.xml.) If "runtime" the attribute's value is not stored in the persistent configuration; the value only exists as long as the resource is running.
* access-type -- String -- One of "read-only", "read-write" or "metric". Whether an attribute value can be written, or can only read. A "metric" is a read-only attribute whose value is not stored in the persistent configuration, and whose value may change due to activity on the server. If an attribute is "read-write", the resource will expose an operation named "write-attribute" whose "name" parameter will accept this attribute's name and whose "value" parameter will accept a valid value for this attribute. That operation will be the standard means of updating this attribute's value.
* restart-required -- String -- One of "no-services", "all-services", "resource-services" or "jvm". Only relevant to attributes whose access-type is read-write. Indicates whether execution of a write-attribute operation whose name parameter specifies this attribute requires a restart of services (or an entire JVM) in order for the change to take effect in the runtime . See discussion of "Applying Updates to Runtime Services" below. Default value is "no-services".
* head-comment-allowed -- boolean -- indicates whether the model can store an XML comment that would be written in the persistent form of the model (e.g. domain.xml) before the start of the XML element that represents this attribute. This item is optional, and if not present defaults to *false*. (This is a different default from is used for an addressable portion of the model, since model attributes often map to XML attributes, which don't allow comments.) +*(Note: storing XML comments in the in-memory model is not currently supported and likely will not be supported in AS 7.1. This description key is for future use.)*+
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates whether a comment just before the close of the XML element is supported. A tail comment can only be supported if the element has child elements, in which case a comment can be inserted between the final child element and the element's closing tag. This item is optional, and if not present defaults to *false*. (This is a different default from is used for an addressable portion of the model, since model attributes often map to XML attributes, which don't allow comments.) +*(Note: storing XML comments in the in-memory model is not currently supported and likely will not be supported in AS 7.1. This description key is for future use.)*+
* arbitrary key/value pairs that further describe the attribute value, e.g. "max" => 2. See "Arbitrary Descriptors" below.
"foo" => {
"description" => "The foo",
"type" => INT,
"max" => 2
}
"bar" => {
"description" => "The bar",
"type" => OBJECT,
"value-type" => {
"size" => INT,
"color" => STRING
}
}
h3. Description of an Operation
An addressable portion of the model may have operations associated with it. The description of an operation will include the following information:
* operation-name -- String -- the name of the operation
* description -- String -- text description of the operation
* request-properties -- Map of String to complex structure -- description of the parameters of the operation. Keys are the names of the parameters, values are descriptions of the parameter value types. See below for details on the description of parameter value types.
* reply-properties -- complex structure, or empty -- description of the return value of the operation, with an empty node meaning void.
* restart-required -- String -- One of "no-services", "all-services", "resource-services" or "jvm". Indicates whether the operation makes a configuration change that requires a restart of services (or an entire JVM) in order for the change to take effect in the runtime. See discussion of "Applying Updates to Runtime Services" below. Default value is "no-services".
h4. Description of an Operation Parameter or Return value
* description -- String -- text description of the parameter or return value
* type -- org.jboss.dmr.ModelType -- the type of the parameter or return value. One of the enum values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT, PROPERTY, STRING.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT. If type is LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, PROPERTY, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT. If type is LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value.
* expressions-allowed -- boolean -- indicates whether the value of the the parameter or return value may be of type ModelType.EXPRESSION, instead its standard type (see type and value-type above for discussion of the standard type.) A value of ModelType.EXPRESSION contains a system-property substitution expression that the server will resolve against the +server-side+ system property map before using the value. For example, a parameter named max-threads may have an expression value of ${example.pool.max-threads:10} instead of just 10. Default value if not present is false.
* required -- boolean -- Only relevant to parameters. true if the parameter must be present in the request object used to invoke the operation; false if it can omitted. If not present, true is the default.
* nillable -- boolean -- true if null is a valid value. If not present, false is the default.
* arbitrary key/value pairs that further describe the attribute value, e.g. "max" =>2. See "Arbitrary Descriptors" below.
{
"operation-name" => "incrementFoo",
"description" => "Increase the value of the 'foo' attribute by the given amount",
"request-properties" => {
"increment" => {
"type" => INT,
"description" => "The amount to increment",
"required" => true
}},
"reply-properties" => {
"type" => INT,
"description" => "The new value",
}
}
{
"operation-name" => "start",
"description" => "Starts the thing",
"request-properties" => {},
"reply-properties" => {}
}
h2. Arbitrary Descriptors
The description of an attribute, operation parameter or operation return value type can include arbitrary key/value pairs that provide extra information. Whether a particular key/value pair is present depends on the context, e.g. a pair with key "max" would probably only occur as part of the description of some numeric type.
Following are standard keys and their expected value type. If descriptor authors want to add an arbitrary key/value pair to some descriptor and the semantic matches the meaning of one of the following items, the standard key/value type must be used.
* min -- int -- the minimum value of some numeric type. The absence of this item implies there is no minimum value.
* max -- int -- the maximum value of some numeric type. The absence of this item implies there is no maximum value.
* min-length -- int -- the minimum length of some string, list or byte[] type. The absence of this item implies a minimum length of zero.
* max-length -- int -- the maximum length of some string, list or byte[]. The absence of this item implies there is no maximum value.
* nillable -- boolean -- whether null is a legal value. The absence of this item implies false; i.e. null is not a legal value.
* allowed -- List -- a list of legal values. The type of the elements in the list should match the type of the attribute.
* default -- the default value for the attribute if not present in the model
* unit - The unit of the value - e.g. ns, ms, s, m, h, KB, MB, TB. See *Measurement Units* below.
h4. Measurement Units
Wherever possible, the description of an attribute, operation parameter or operation return value should include the unit arbitrary descriptor. Valid values for this descriptor are:
// Simple Unit Types
NONE
PERCENTAGE
// Absolute Sizes in Bytes (utilization)
BYTES
KILOBYTES
MEGABYTES
GIGABYTES
TERABYTES
PETABYTES
// Absolute Sizes in Bits (throughput)
BITS
KILOBITS
MEGABITS
GIGABITS
TERABITS
PETABITS
// Absolute Time - no display, only hints to the UI how to display
EPOCH_MILLISECONDS
EPOCH_SECONDS
// Relative Time
JIFFYS
NANOSECONDS
MICROSECONDS
MILLISECONDS
SECONDS
MINUTES
HOURS
DAYS
// Rate
PER_JIFFY
PER_NANOSECOND
PER_MICROSECOND
PER_MILLISECOND
PER_SECOND
PER_MINUTE
PER_HOUR
PER_DAY
// Temperature
CELSIUS
KELVIN
FAHRENHEIGHT
Legal values are listed in the https://github.com/jbossas/jboss-as/blob/master/controller-client/src/mai... MeasurementUnit enum. This enum is in the controller-client package, and is thus usable by java-based management clients.
h2. Description of Parent/Child Relationships
The address used to target an addressable portion of the model must be an ordered list of key value pairs. The effect of this requirement is the addressable portions of the model naturally form a tree structure, with parent nodes in the tree defining what the valid keys are and the children defining what the valid values are. The parent node also defines the cardinality of the relationship. The description of the parent node includes a children element that describes these relationships:
{
....
"children" => {
"connector" => {
.... description of the relationship with children of type "connector"
},
"virtual-host" => {
.... description of the relationship with children of type "virtual-host"
}
}
The description of each relationship will include the following elements:
* description -- String -- text description of the relationship
* min-occurs -- int, either 0 or 1 -- Minimum number of children of this type that must exist in a valid model. If not present, the default value is 0.
* max-occurs -- int -- Maximum number of children of this type that may exist in a valid model. If not present, the default value is Integer.MAX_VALUE, i.e. there is no limit.
* allowed -- List of strings -- legal values for children names. If not present, there is no restriction on children names.
* model-description -- either "undefined" or a complex structure -- This is the full description of the child resource (its text description, attributes, operations, children) as detailed above. This may also be "undefined", i.e. a null value, if the query that asked for the parent node's description did not include the "recursive" param set to true.
Example with if the recursive flag was set to true:
{
"description" => "The connectors used to handle client connections",
"min-occurs" > 1,
"model-description" => {
"description" => "Handles client connections",
"attributes => {
... details of children as documented above
},
"operations" => {
.... details of operations as documented above
},
"children" => {
.... details of the children's children
}
}
}
If the recursive flag was false:
{
"description" => "The connectors used to handle client connections",
"min-occurs" > 1,
"model-description" => undefined
}
h2. Applying Updates to Runtime Services
An attribute or operation description may include a "restart-required" descriptor; this section is an explanation of the meaning of that descriptor.
An operation that changes a management resource's persistent configuration usually can also also affect a runtime service associated with the resource. For example, there is a runtime service associated with any host.xml or standalone.xml <interface> element; other services in the runtime depend on that service to provide the InetAddress associated with the interface. In many cases, an update to a resource's persistent configuration can be immediately applied to the associated runtime service. The runtime service's state is updated to reflect the new value(s).
However, in many cases the runtime service's state cannot be updated without restarting the service. Restarting a service can have broad effects. A restart of a service A will trigger a restart of other services B, C and D that depend A, triggering a restart of services that depend on B, C and D, etc. Those service restarts may very well disrupt handling of end-user requests.
Because restarting a service can be disruptive to end-user request handling, the handlers for management operations will not restart any service without some form of explicit instruction from the end user indicating a service restart is desired. In a few cases, simply executing the operation is an indication the user wants services to restart (e.g. a /host=master/server-config=server-one:restart operation in a managed domain, or a /:reload operation on a standalone server.) For al other cases, if an operation (or attribute write) cannot be performed without restarting a service, the metadata describing the operation or attribute will include a "restart-required" descriptor whose value indicates what is necessary for the operation to affect the runtime:
* no-services -- Applying the operation to the runtime does not require the restart of any services. This value is the default if the restart-required descriptor is not present.
* all-services -- The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of all services in the affected VM. Executing the operation will put the server into a "reload-required" state. Until a restart of all services is performed the response to this operation and to any subsequent operation will include a response header "process-state" => "reload-required". For a standalone server, a restart of all services can be accomplished by executing the /:reload CLI command. For a server in a managed domain, restarting all services currently requires a full restart of the affected server VM (e.g. /host=master/server-config=server-one:restart).
* jvm --The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a full process restart (i.e. stop the JVM and launch a new JVM). Executing the operation will put the server into a "restart-required" state. Until a restart is performed the response to this operation and to any subsequent operation will include a response header "process-state" => "restart-required". For a standalone server, a full process restart requires first stopping the server via OS-level operations (Ctrl-C, kill) or via the /:shutdown CLI command, and then starting the server again from the command line. For a server in a managed domain, restarting a server requires executing the /host=<host>/server-config=<server>:restart operation.
* resource-services -- The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.)
h2. Example Representation of a Portion of the Domain Controller API
{
"description" => "The root node of the domain-level management model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the configuration XML document, where keys are namespace prefixes and values are schema URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in the configuration XML document, where keys are schema URIs and values are locations where the schema can be found.",
"required" => false
}
},
"operations" => "TODO",
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths. The paths may or may not be fully specified (i.e. include the actual paths.)",
"model-description" => {
"description" => "A named filesystem path, but without a requirement to specify the actual path. If no actual path is specified, acts as a placeholder in the model (e.g. at the domain level) until a fully specified path definition is applied at a lower level (e.g. at the host level, where available addresses are known.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot be one of the standard fixed paths provided by the system: <ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li></ul> Note that the system provides other standard paths that can be overridden by declaring them in the configuration file. See the 'relative-to' attribute documentation for a complete list of standard paths.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"required" => false,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path' child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path' child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the 'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the 'path' attribute",
"required" => true,
"min-length" => 1,
"nillable" => true
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the 'relative-to' attribute",
"request-properties" => {"relative-to" => {
"type" => STRING,
"description" => "The new value of the 'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"profile" => {
"description" => "A list of profiles available for use in the domain",
"min-occurs" => 1,
"model-description" => {
"description" => "A named set of subsystem configurations.",
"attributes" => {"name" => {
"type" => STRING,
"description" => "The name of the profile",
"required" => true,
"min-length" => 1
}},
"operations" => {},
"children" => {
"subsystem" => {
"description" => "The subsystems that make up the profile.",
"min-occurs" => 1,
"model-description" => {}
},
"include" => {"model-description" => {
"description" => "Specifies that a contents of a named profile are to be included in the profile whose definition includes this item.",
"head-comment-allowed" => true,
"tail-comment-allowed" => false,
"attributes" => {"profile" => {
"type" => LIST,
"description" => "The name of the included profile",
"required" => true,
"value-type" => STRING
}},
"operations" => "TODO"
}}
}
}
},
"interface" => {
"description" => "A list of named network interfaces available for use in the domain. The interfaces may or may not be fully specified (i.e. include criteria on how to determine their IP address.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"socket-binding-group" => {
"description" => "A list of socket binding groups available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"system-property" => {
"description" => "A list of system properties to set on all servers in the domain.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"deployment" => {
"description" => "A list of deployments available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"server-group" => {
"description" => "A list of server groups available for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"host" => {
"description" => "Host controllers currently running in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
}
}
}
h2. Example Representation of a Portion of the Host Controller API
{
"description" => "The root node of the host-level management model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the configuration XML document, where keys are namespace prefixes and values are schema URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in the configuration XML document, where keys are schema URIs and values are locations where the schema can be found.",
"required" => false
},
"management" => {
"description" => "Configuration of the host's management system.",
"type" => OBJECT,
"value-type" => {
"interface" => {
"type" => STRING,
"description" => "Interface on which the host's socket for intra-domain management communication should be opened.",
"required" => false
},
"port" => {
"type" => STRING,
"description" => "Port on which the host's socket for intra-domain management communication should be opened.",
"required" => false
}
},
"required" => true,
"head-comment-allowed" => true
},
"domain-controller" => {
"description" => "Configuration of how the host should interact with the Domain Controller",
"type" => OBJECT,
"value-type" => "TODO",
"required" => true,
"head-comment-allowed" => true,
"tail-comment-allowed" => true
}
},
"operations" => {
"start-server" => {
"operation-name" => "start-server",
"description" => "Start a server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
},
"restart-server" => {
"operation-name" => "restart-server",
"description" => "Restart a currently running server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
},
"stop-server" => {
"operation-name" => "stop-server",
"description" => "Stop a currently running server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following execution of this operation."
}
}
},
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths.",
"min-occurs" => 0,
"model-description" => {
"description" => "A named filesystem path, but without a requirement to specify the actual path. If no actual path is specified, acts as a placeholder in the model (e.g. at the domain level) until a fully specified path definition is applied at a lower level (e.g. at the host level, where available addresses are known.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot be one of the standard fixed paths provided by the system: <ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li></ul> Note that the system provides other standard paths that can be overridden by declaring them in the configuration file. See the 'relative-to' attribute documentation for a complete list of standard paths.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path' child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1
},
"path" => {
"type" => STRING,
"description" => "The value of the path's 'path' attribute",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path' child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the path's 'name' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the 'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the 'path' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the 'relative-to' attribute",
"request-properties" => {"relative-to" => {
"type" => STRING,
"description" => "The new value of the 'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"system-property" => {
"description" => "A list of system properties to set on all servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"interface" => {
"description" => "A list of fully specified named network interfaces available for use on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"jvm" => {
"description" => "A list of Java Virtual Machine configurations that can be applied ot servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"server-config" => {
"description" => "Host-level configurations for the servers that can run on this host.",
"min-occurs" => 0
"model-description" => {}
},
"server" => {
"description" => "Servers currently running on the host",
"min-occurs" => 0
"model-description" => "TODO"
}
}
}
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16317]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 5 months
- 1
- 0