[JBoss AS 7 Development] - JBoss AS7 Command-line Operation Request Format
by Alexey Loubyansky
Alexey Loubyansky [https://community.jboss.org/people/aloubyansky] created the document:
"JBoss AS7 Command-line Operation Request Format"
To view the document, visit: https://community.jboss.org/docs/DOC-17599
--------------------------------------------------------------
For the definition and description of the AS7 management operation request, please, refer to the https://community.jboss.org/docs/DOC-16336 Format of a detyped operation request.
This article describes only the format of the operation request in the command-line interface, which is
[node_path] : operation_name [parameter_list] [header_list]
As you can see, all the parts except the +operation_name+ preceded with ':' are optional.
node_path := node_type=node_name (, node_type=node_name)*
parameter_list := '(' parameter_name=parameter_value (,parameter_name=parameter_value)* ')'
header_list := {header (;header)*}
h3. Address (node path)
+node_path+ represents the address of the target resource (or the node) against which the operation should be invoked. It consists of +node_type=node_name+ pairs separated by a comma:
node_type=node_name (, node_type=node_name)*
E.g.
+/subsystem=datasources+
or
+/subsystem=datasources/data-source=ExampleDS+
etc.
h3. Operation
The operation consists of an operation name and an optional list of parameters. The operation name is always preceded by a colon. The colon serves as a separator between the +node_path+ and the operation. Even if the +node_path+ is empty, the colon is still required. This is also how an operation is different from a command (commands are not preceded with a colon).
The parameter list, if present, is surrounded with parentheses and consists of +parameter_name=parameter_value+ pairs separated by commas:
:operation-name ['(' [name=value [, name=value]*] ')']
E.g.
+:shutdown+
+:shutdown()+
+:shutdown(restart=true)+
+/subsystem=datasources/data-source=ExampleDS:write-attribute(name=min-pool-size,value=5)+
h3. Headers
If present, the header list is surrounded with curly braces. The headers in the list are separated by a semicolon. The syntax of headers may vary. Simple headers follow +header_name=header_value+ format. But there are also headers (like rollout plans) that require a more complex custom expression. Here is an example of an operation with simple headers:
+:write-attribute(name=my-attr,value=my-value){allow-resource-service-restart=true;rollback-on-runtime-failure=false}+
h3. Rollout plans
For the definition and explanation of what rollout plans are and for, please, refer to the section *Operations with a Rollout Plan* of the https://community.jboss.org/docs/DOC-16336 Format of a detyped operation request.
This article only describes the CLI format of a rollout plan which is
rollout server_group_list [rollback-across-groups]
server_group_list := server_group [ (sequence_separator | concurrent_separator) server_group ]
sequence_separator := ','
concurrent_separator := '^'
server_group := server_group_name [group_policy_list]
group_policy_list := '(' policy_property_name=policy_property_value (, policy_property_name=policy_property_value)* ')'
policy_property_name := 'rolling-to-servers' | 'max-failed-servers' | 'max-failure-percentage'
The value of +policy_property_value+ depends on the property. It can be a boolean, an integer, etc. You can fine the definition and description of each of the policy properties in
the section *Operations with a Rollout Plan* of the https://community.jboss.org/docs/DOC-16336 Format of a detyped operation request.
Here are a few examples.
Rollout the operation in sequence first to main-server-group than the other-server-group:
+:write-attribute(name=my-attr,value=my-value){rollout main-server-group,other-server-group}+
Rollout the operation concurrently to main-server-group and the other-server-group:
+:write-attribute(name=my-attr,value=my-value){rollout main-server-group^other-server-group}+
Rollout the operation in sequence to groupA, concurrently to groupB and groupC and then to groupD using the specified policies and rollback across all the groups in case of a failure.
+:write-attribute(name=my-attr,value=my-value){rollout groupA, groupB(max-failed-servers=1) ^ groupC(max-failure-percentage=10), groupD(max-failed-servers=2, rolling-to-servers=true) rollback-across-groups}+
h4. Headers in commands
Headers are also allowed for the commands that translate into operation requests. Those commands accept argument +--headers+ the value of which is header-list defined above. I.e. the syntax for headers for operations and commands is exactly the same, e.g.
+data-source --profile=default --name=ExampleDS --min-pool-size=5 --headers={rollout groupA, groupB(max-failed-servers=1) ^ groupC(max-failure-percentage=10), groupD(max-failed-servers=2, rolling-to-servers=true) rollback-across-groups}+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17599]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 2 months
[JBoss AS 7 Development] - Re: does ModuleClassLoader support class array syntax?
by Enguerrand Dibanda
Enguerrand Dibanda [https://community.jboss.org/people/enguerrandd] created the discussion
"Re: does ModuleClassLoader support class array syntax?"
To view the discussion, visit: https://community.jboss.org/message/720132#720132
--------------------------------------------------------------
Hi,
does this actually means that this feature in now "out of the box" and the system property
-Dsun.lang.ClassLoader.allowArraySyntax=true doesnt have to be set anymore?
I'm currently having the following problem while using JBoss 7.1.0.Final:
* I set the -Dsun.lang.ClassLoader.allowArraySyntax=true propery and can see that it is passed to the JVM at boot
10:12:14,514 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.1.GA
10:12:14,886 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA
10:12:15,028 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015899: JBoss AS 7.1.0.Final "Thunder" starting
10:12:15,030 DEBUG [org.jboss.as.config] (MSC service thread 1-4) Configured system properties:
...
sun.jnu.encoding = UTF-8
sun.lang.ClassLoader.allowArraySyntax = true
sun.management.compiler = HotSpot 64-Bit Tiered Compilers
...
user.timezone = Europe/Berlin
10:12:15,049 DEBUG [org.jboss.as.config] (MSC service thread 1-4) VM Arguments: -D[Server:dcs1] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1536m -Xmx1536m -Xss256k -XX:+UseParallelGC -XX:ParallelGCThreads=16 -XX:+DisableExplicitGC ... -Dsun.lang.ClassLoader.allowArraySyntax=true ... -Dlogging.configuration=file:/usr/local/jboss/domain/configuration/logging.properties
10:12:15,300 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.3.GA
10:12:15,316 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.3.GA
10:12:15,325 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.2.GA
10:12:22,995 INFO [org.jboss.as.logging] (MSC service thread 1-3) JBAS011502: Removing bootstrap log handlers
* I can't however see this system property when I query all system properties over the CLI
[domain@localhost:9999 /] /host=dcs1/core-service=platform-mbean/type=runtime:read-attribute(name=system-properties)
...
"sun.jnu.encoding" => "UTF-8",
"sun.management.compiler" => "HotSpot 64-Bit Tiered Compilers",
...
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/720132#720132]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 2 months
[JBoss AS 7 Development] - Logging Id's
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:
"Logging Id's"
To view the document, visit: https://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| P | = | Merged, but not complete |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI (not applicable)
* | N/A |
| *10600 - 10699* | *Controller Client* | C |
| *10700 - 10799, 18500 - 18699, 18800-18999* | *CMP* | I |
| *10800 - 10899* | *Host Controller (domain packages)* | C |
| *10900 - 10999* | *Host Controller (host packages)* | C |
| *11000 - 11099* | *EE* | C |
| *11100 - 11199* | *Embedded* | C |
| *11200 - 11299* | *JAXRS* | C |
| *11300 - 11399* | *JMX* | C |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *12200 - 12299* | *Management Client Content* | C |
| *12300 - 12399* | *Platform MBeans* | C |
| *12400 - 12499* | *Threads* | C |
| *13100 - 13199* | *Security* | C |
| *13200 - 13299* | *AppClient* | C |
| *13300 - 13399* | *JDR* | C |
| *14000 - 14099* | *JAXR* | W |
| *14100 - 14599* | *Ejb3* | P |
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Domain Management HTTP Interface* | C |
| *15200 - 15299* | *Deployment Management* | C |
| *15300 - 15399* | *Network* | C |
| *15400 - 15499* | *Mail* | C |
| *15500 - 15699* | *Web Services* | C |
| *15700 - 15999, 18700 - 18799* | *Server* | C |
| *1**6000 - 16099* | *Weld* | C |
| *16100 - 16199* | *EE Deployment* | C |
| *16200 - 16299* | *Configadmin* | C |
| *16300 - 16499* | *Jacorb* | C |
| available block(s) |
|
|
| *17000 - 17099* | *POJO* | C |
| *17100 - 17199* | *Remoting* | W |
| *17200 - 17299* | *SAR* | W |
| *18000 - 18399* | *Web* | C |
| *18400 - 18499* | *Xts* | C |
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 2 months
[JBoss AS 7 Development] - moving from 7.0.1 to 7.1final , getting NoClassDefFoundError
by robert walker
robert walker [https://community.jboss.org/people/robertwalker] created the discussion
"moving from 7.0.1 to 7.1final , getting NoClassDefFoundError"
To view the discussion, visit: https://community.jboss.org/message/719981#719981
--------------------------------------------------------------
hi all, i am trying to move to the new 7.1.0 from the 7.0.1 release. I have no errors in 7.0.1
I only have 1 deployed webapp, and apparently something is not being found.
I do indeed have a 7.1.0.Final/modules/org/apache/log4j/main/log4j-1.2.16.jar so unsure why is is stating NoClassDefFoundError: org/apache/log4j/Priority
maybe it is not really not found but more of a conflict error, but not sure where to begin
thanks all
.... and BTW, great app server! we are using jee 6 type structure/technologies with stateless session beans and richfaces 4, great stuff!!!!
13:26:02,751 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-1) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.logging.Log4jLogger
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0.10]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0.10]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0.10]
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Priority
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0.10]
at java.lang.Class.privateGetDeclaredFields(Class.java:2318) [rt.jar:1.6.0.10]
at java.lang.Class.getDeclaredFields(Class.java:1747) [rt.jar:1.6.0.10]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:153) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
... 11 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Priority from [Module "org.jboss.logging:main" from local module loader @b01d43 (roots: /opt/app/jboss-as-7.1.0.Final/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
... 29 more
13:26:02,913 INFO [org.jboss.seam.solder.core.CoreExtension] (MSC service thread 1-1) Preventing class org.jboss.seam.solder.resourceLoader.ResourceProvider from being installed as bean due to @Veto annotat
ion
13:26:02,991 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-1) WELD-000119 Not generating any bean definitions from org.jboss.logging.Slf4jLogger because of underlying class loading error
13:26:02,993 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-1) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.logging.Slf4jLogger
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0.10]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0.10]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0.10]
Caused by: java.lang.NoClassDefFoundError: Lorg/slf4j/Logger;
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0.10]
at java.lang.Class.privateGetDeclaredFields(Class.java:2318) [rt.jar:1.6.0.10]
at java.lang.Class.getDeclaredFields(Class.java:1747) [rt.jar:1.6.0.10]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:153) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) [guava-r08.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
... 11 more
Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger from [Module "org.jboss.logging:main" from local module loader @b01d43 (roots: /opt/app/jboss-as-7.1.0.Final/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
... 29 more
13:26:03,028 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-1) WELD-000119 Not generating any bean definitions from org.jboss.logging.Slf4jLocationAwareLogger because of underlying class loading e
rror
13:26:03,030 INFO [org.jboss.weld.ClassLoading] (MSC service thread 1-1) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.logging.Slf4jLocationAwareLogger
at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/719981#719981]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 2 months
[JBoss AS 7 Development] - Logging Id's
by John Bailey
John Bailey [https://community.jboss.org/people/johnbailey] modified the document:
"Logging Id's"
To view the document, visit: https://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| P | = | Merged, but not complete |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI (not applicable)
* | N/A |
| *10600 - 10699* | *Controller Client* | C |
| *10700 - 10799, 18500 - 18699, 18800-18999* | *CMP* | I |
| *10800 - 10899* | *Host Controller (domain packages)* | C |
| *10900 - 10999* | *Host Controller (host packages)* | C |
| *11000 - 11099* | *EE* | C |
| *11100 - 11199* | *Embedded* | C |
| *11200 - 11299* | *JAXRS* | C |
| *11300 - 11399* | *JMX* | C |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *12200 - 12299* | *Management Client Content* | C |
| *12300 - 12399* | *Platform MBeans* | C |
| *12400 - 12499* | *Threads* | C |
| *13100 - 13199* | *Security* | C |
| *13200 - 13299* | *AppClient* | C |
| *13300 - 13399* | *JDR* | C |
| *14000 - 14099* | *JAXR* | W |
| *14100 - 14599* | *Ejb3* | P |
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Deployment HTTP API* | C |
| *15200 - 15299* | *Deployment Management* | C |
| *15300 - 15399* | *Network* | C |
| *15400 - 15499* | *Mail* | C |
| *15500 - 15699* | *Web Services* | C |
| *15700 - 15999, 18700 - 18799* | *Server* | C |
| *1**6000 - 16099* | *Weld* | C |
| *16100 - 16199* | *EE Deployment* | C |
| *16200 - 16299* | *Configadmin* | C |
| *16300 - 16499* | *Jacorb* | C |
| available block(s) |
|
|
| *17000 - 17099* | *POJO* | C |
| *17100 - 17199* | *Remoting* | W |
| *17200 - 17299* | *SAR* | W |
| *18000 - 18399* | *Web* | C |
| *18400 - 18499* | *Xts* | C |
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 2 months
[JBoss AS 7 Development] - JBoss AS7 Command-line public API
by Alexey Loubyansky
Alexey Loubyansky [https://community.jboss.org/people/aloubyansky] modified the document:
"JBoss AS7 Command-line public API"
To view the document, visit: https://community.jboss.org/docs/DOC-17597
--------------------------------------------------------------
(Since JBoss AS 7.1.1)
This article describes how to start a CLI session to execute commands and operations from a Java application or to simply leverage the functionality implemented in the CLI to, e.g., only translate commands and operations from their string form into DMR operation requests and execute them using another client.
h3. Example
Here is a simple example (which is explained in detail below) that takes a snapshot of the current server's configuration (the operation +:take-snapshot+) and then deploys myapp.ear (command +deploy+). These two actions were chosen just as an example of an operation and a command.
// Initialize the CLI context
final CommandContext ctx;
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
} catch(CliInitializationException e) {
throw new IllegalStateException("Failed to initialize CLI context", e);
}
try {
// connect to the server controller
ctx.connectController();
// execute commands and operations
ctx.handle(":take-snapshot");
ctx.handle("deploy myapp.ear");
} catch (CommandLineException e) {
// the operation or the command has failed
} finally {
// terminate the session and
// close the connection to the controller
ctx.terminateSession();
}
h3. Starting a CLI session
The main interface, which represents a CLI session, is +org.jboss.as.cli.CommandContext+. This interface declares methods to connect to the server's controller, execute commands and operations and much more. So, the first step to start a CLI session is to obtain an instance of this interface. The simplest way to do it is
final CommandContext ctx;
try {
ctx = org.jboss.as.cli.CommandContextFactory.getInstance().newCommandContext();
} catch (CliInitializationException e) {
// handle the exception
}
There are a few other versions of the +newCommandContext()+ that accept username and password, default controller host and port, in case you need to change the default values.
h3. Connecting to the controller
Normally, the next step will be to connect to the server controller. This can be done by invoking one of the +connectController()+ methods. E.g. the following method will attempt to connect using the default host and port (which is localhost:9999 or the ones provided at the +CommandContext+ construction time).
ctx.connectionController();
If the target controller is not at the default host and port, the host and port can be specified
ctx.connectController(host, port);
Both of these methods throw an instance of +org.jboss.as.cli.CommandLineException+ in case the connection failed.
h3. Executing commands and operations
Another way to connect to the controller would be to simply execute the +connect+ command. Like any other CLI command or an operation, it can be executed using +void handle(String line)+ method
try {
ctx.handle("connect");
} catch(CommandLineException e) {
// command failed
}
The +handle+ method throws an instance of +CommandLineException+ in case the command or the operation fails. If you are not interested in catching exceptions, there is +void handleSafe(String line)+ method, which actually invokes the +handle+ method but catches +CommandLineException+, logs it and sets the context's error code to a non-zero value which can be checked after the method has returned.
ctx.handleSafe("connect");
if(ctx.getExitCode != 0) {
// connect failed
}
The exit code is reset automatically to zero before each command or an operation is executed.
Now, when the connection is established, any CLI command or an operation request can be executed using +handle+ or +handleSafe+ method. E.g.
ctx.handleSafe(":take-snapshot"); // an example of an operation
ctx.handleSafe("deploy myapp.ear"); // an example of a command
h3. Building and executing DMR requests
In case you want to execute DMR requests yourself, you can use the +CommandContext+ to translate commands and operations to DMR requests. E.g.
ModelNode deployRequest;
try {
ModelNode deployRequest = ctx.buildRequest("deploy myapp.ear");
} catch (CommandFormatException e) {
// there was a problem building a DMR request
}
Then you can execute DMR requests using the context's controller client, e.g.
ModelControllerClient client = ctx.getModelControllerClient();
if(client != null) {
try {
client.execute(deployRequest);
} catch (IOException e) {
// client failed to execute the request
}
} else {
// the client is not available, meaning the connection to the controller
// has not been established, which means ctx.connectController(...)
// or ctx.handle("connect") haven't been executed before
}
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17597]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 2 months
[JBoss AS 7 Development] - JBoss AS7 Command-line public API
by Alexey Loubyansky
Alexey Loubyansky [https://community.jboss.org/people/aloubyansky] created the document:
"JBoss AS7 Command-line public API"
To view the document, visit: https://community.jboss.org/docs/DOC-17597
--------------------------------------------------------------
(Since JBoss AS 7.1.1)
This article describes how to start a CLI session to execute commands and operations from a Java application or to simply leverage the functionality implemented in the CLI to, e.g., only translate commands and operations from their string form into DMR operation requests.
h3. Example
Here is a simple example (which is explain in detail below) that takes a snapshot of the current server's configuration (the operation +:take-snapshot+) and then deploys myapp.ear (command +deploy+). These two actions were chosen just as an example of an operation and a command.
// Initialize the CLI context
final CommandContext ctx;
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
} catch(CliInitializationException e) {
throw new IllegalStateException("Failed to initialize CLI context", e);
}
try {
// connect to the server controller
ctx.connectController();
// execute commands and operations
ctx.handle(":take-snapshot");
ctx.handle("deploy myapp.ear");
} catch (CommandLineException e) {
// one of the commands has failed
} finally {
// terminate the session and
// close the connection to the controller
ctx.terminateSession();
}
h3. Starting a CLI session
The main interface, which represents a CLI session, is +org.jboss.as.cli.CommandContext+. This interface declares methods to connect to the server's controller, execute commands and operations and much more. So, the first step to start a CLI session is to obtain an instance of this interface. The simplest way to do it is
final CommandContext ctx;
try {
ctx = org.jboss.as.cli.CommandContextFactory.getInstance().newCommandContext();
} catch (CliInitializationException e) {
// handle the exception
}
There are a few other versions of the +newCommandContext()+ that accept username and password, default controller host and port, in case you need to change the default values.
h3. Connecting to the controller
Normally, the next step will be to connect to the server controller. This can be done by invoking one of the +connectController()+ methods. E.g. the following method will attempt to connect using the default host and port (which is localhost:9999 or the ones provided at the +CommandContext+ construction time).
ctx.connectionController();
If the target controller is not at the default host and port, the host and port can be specified
ctx.connectController(host, port);
Both of these methods throw an instance of +org.jboss.as.cli.CommandLineException+ in case the connection failed.
h3. Executing commands and operations
Another way to connect to the controller would be to simply execute the +connect+ command. Like any other CLI command or operation, it can be executed using +void handle(String line)+ method
try {
ctx.handle("connect");
} catch(CommandLineException e) {
// command failed
}
The handle method throws an instance of +CommandLineException+ in case the command or the operation fails. If you are not interested in catching exceptions, there is +void handleSafe(String line)+ method, which actually invokes the handle method but catches +CommandLineException+, logs it and sets the context's error code to a non-zero value which can be checked after the method has returned.
ctx.handleSafe("connect");
if(ctx.getExitCode != 0) {
// connect failed
}
The exit code is reset automatically to zero before each command or operation is executed.
Now, when the connection is established, any CLI command or operation request can be executed using handle or +handleSafe+ method. E.g.
ctx.handleSafe(":take-snapshot"); // an example of an operation
ctx.handleSafe("deploy myapp.ear"); // an example of a command
h3. Building and executing DMR requests
In case you want to execute DMR requests yourself. You can use the +CommandContext+ to translate commands and operations to DMR requests. E.g.
ModelNode deployRequest;
try {
ModelNode deployRequest = ctx.buildRequest("deploy myapp.ear");
} catch (CommandFormatException e) {
// there was a problem building a DMR request
}
Then you can execute DMR requests using the context's controller client, e.g.
ModelControllerClient client = ctx.getModelControllerClient();
if(client != null) {
try {
client.execute(deployRequest);
} catch (IOException e) {
// client failed to execute the request
}
} else {
// the client is not available, meaning the connection to the controller
// has not been established, which means ctx.connectController(...)
// or ctx.handle("connect") haven't been executed before
}
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17597]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 2 months