[JBoss AS7 Development] - ConcurrentModificationException Error when deploying the struts1.3.5 application on Jboss 7
by leo li
leo li [http://community.jboss.org/people/leo87601] created the discussion
"ConcurrentModificationException Error when deploying the struts1.3.5 application on Jboss 7"
To view the discussion, visit: http://community.jboss.org/message/630555#630555
--------------------------------------------------------------
Dear all,
Please help us to reslove this problem. And the application are working fine in the Websphere Appolication 7, and we want to migrate them to Jboss7.
We have some user define taglib which is a sub class of the "NestedIterateTag" (org.apache.struts.taglib.nested.logic.NestedIterateTag) in a struts1.3.5 application on Jboss 7.
The jsp page are working fine on our first click in the page, but it will faild when we click the page again.
The error are following:
Servlet.service() for servlet action threw exception: java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) [:1.6.0_13]
at java.util.AbstractList$Itr.next(AbstractList.java:343) [:1.6.0_13]
at org.apache.struts.taglib.logic.IterateTag.doAfterBody(IterateTag.java:377) [struts-taglib-1.3.5.jar:]
at org.apache.struts.taglib.nested.logic.NestedIterateTag.doAfterBody(NestedIterateTag.java:124) [struts-taglib-1.3.5.jar:]
at .******..****.taglib.dataset.RowTemplateTag.doAfterBody(RowTemplateTag.java:52) [classes:]
at org.apache.jsp.fw.jsp.acl.manageFunctionLeaf_jsp._jspService(manageFunctionLeaf_jsp.java:765)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:253) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:541) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.struts.chain.commands.servlet.PerformForward.handleAsForward(PerformForward.java:99) [struts-core-1.3.5.jar:]
at org.apache.struts.chain.commands.servlet.PerformForward.perform(PerformForward.java:82) [struts-core-1.3.5.jar:]
at org.apache.struts.chain.commands.AbstractPerformForward.execute(AbstractPerformForward.java:51) [struts-core-1.3.5.jar:]
at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:48) [struts-core-1.3.5.jar:]
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) [commons-chain-1.1.jar:]
at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304) [commons-chain-1.1.jar:]
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190) [commons-chain-1.1.jar:]
at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:280) [struts-core-1.3.5.jar:]
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1858) [struts-core-1.3.5.jar:]
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:446) [struts-core-1.3.5.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at crown.fw.filter.authorization.AccessControlFilter.checkAccessPermissions(AccessControlFilter.java:285) [classes:]
at crown.fw.filter.authorization.AccessControlFilter.doFilter(AccessControlFilter.java:187) [classes:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:480) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_13]
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630555#630555]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 3 months
[JBoss Transactions Development] - Remote txinflow: XID changes
by Tom Jenkinson
Tom Jenkinson [http://community.jboss.org/people/tomjenkinson] created the discussion
"Remote txinflow: XID changes"
To view the discussion, visit: http://community.jboss.org/message/629621#629621
--------------------------------------------------------------
Just to get the ball rolling on this part of this design discussion, we need to consider how best to update XidImple to allow the recovery manager to detect transactions managed by this node as the status quo would leave transactions that flowed to remote servers un-recoverable as the recovery manager checks the node name encoded in the XidImple would not have the same node ID as the local server. Also, branches passed to the XAResources would be the same branch and this could have undesired behavior in the XAResources.
David suggests one approach:
David Lloyd wrote:
You could however use integer packing to make more room; in such a scheme, the bqual bits which identify the node would still be an integer sequence but would work like this:
For this to work you'd have to treat 0000 as a special padding sequence for the case where only one nybble of the last byte is used. Thus giving:
0000: padding
0001-0111: resources 0-6
1000 0000-1011 1111: resources 7-70
1100 0000 0000-1101 1111 1111: resources 71-582
etc.
Node names are currently recorded as variable length Strings, one option is to cat the new node name onto the end of the bqual resulting in:
Xid {
formatId
gtrid - uid + nodename
bqual - [uid (for the sequence number) + jndi name] + [nodename of the subordinate]
}
This will keep the bquals unique between TMs and will facitilitate recovery of this transaction.
To be continued...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/629621#629621]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 3 months
[JBoss AS7 Development] - Format of a Detyped Operation Response
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Format of a Detyped Operation Response"
To view the document, visit: http://community.jboss.org/docs/DOC-16354
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use is 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 the return value.
For the format of the request, see this page (http://community.jboss.org/docs/DOC-16336).
See http://community.jboss.org/docs/DOC-16317 this page for a more in depth example of using the native management API.
h3. Simple Responses
Simple responses are provided by the following types of operations:
* Non-composite operations that target a single server. (See below for more on composite operations).
* Non-composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a simple read of a domain configuration property.)
The response will always include a simple boolean outcome field, with one of three possible values:
* success -- the operation executed successfully
* failed -- the operation failed
* cancelled -- the execution of the operation was cancelled. (This would be an unusual outcome for a simple operation which would generally very rapidly reach a point in its execution where it couldn't be cancelled.)
The other fields in the response will depend on whether the operation was sucessful.
The response for a failed operation:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message"
}
A response for a successful operation will include an additional field:
* result -- the return value, or undefined for void operations or those that return null
A non-void result:
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
}
}
A void result with a compensating operation:
{
"outcome" => "success",
"result" => undefined
}
The response for a cancelled operation has no other fields:
{
"outcome" => "cancelled"
}
h3.
h3. Response Headers
Besides the standard outcome, result and failure-description fields described above, the response may also include various headers that provide more information about the affect of the operation or about the overall state of the server. The headers will be child element under a field named response-headers. For example:
{
"outcome" => "success",
"result" => undefined,
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
A response header is typically related to whether an operation could be applied to the targetted runtime without requiring a restart of some or all services, or even of the target process itself. Please see "Applying Updates to Runtime Services" on the http://community.jboss.org/docs/DOC-16317 Detyped Description of the AS 7 Management Model wiki for a discussion of the basic concepts related to what happens if an operation requires a service restart to be applied.
The current possible response headers are:
* operation-requires-reload -- boolean -- indicates that the specific operation that has generated this response requires a restart of all services in the process in order to take effect in the runtime. This would typically only have a value of 'true'; the absence of the header is the same as a value of 'false.'
* operation-requires-restart -- boolean -- indicates that the specific operation that has generated this response requires a full process restart in order to take effect in the runtime. This would typically only have a value of 'true'; the absence of the header is the same as a value of 'false.'
* process-state -- enumeration -- Provides information about the overall state of the target process. One of the following values:* starting -- the process is starting
* running -- the process is in a normal running state. The process-state header would typically not be seen with this value; the absence of the header is the same as a value of 'running'.
* reload-required -- some operation (not necessarily this one) has executed that requires a restart of all services in order for a configuration change to take effect in the runtime.
* restart-required -- some operation (not necessarily this one) has executed that requires a full process restart in order for a configuration change to take effect in the runtime.
* stopping -- the process is stopping
h3. Basic Composite Operation Responses
A composite operation is one that incorporates more than one simple operation in a list and executes them atomically. See the "Composite Operations" section http://community.jboss.org/docs/DOC-16336 here for more information.
Basic composite responses are provided by the following types of operations:
* Composite operations that target a single server.
* Composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a list of simple reads of domain configuration properties.)
The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure header field. If that field was false (default is true), the outcome flag will be success if *any* of the composite operation's steps was successful.
What's distinctive about a composite operation response is the result field. First, even if the operation was not successful, the result field will usually be present. (It won't be present if there was some sort of immediate failure that prevented the responder from even attempting to execute the individual operations.) Second, the content of the result field will be a list. Each element in the list will record the result of the corresponding element in the steps field of the composite operation request. So each individual operation in the composite operation will have its result recorded.
The individual operation results will have the same basic format as the simple operation results described above. However, there are some differences from the simple operation case when the individual operation's outcome flag is failed. These relate to the fact in a composite operation, individual operations can be rolled back or not even attempted.
If an individual operation was not even attempted (because the overall operation was cancelled or, more likely, a prior operation failed):
{
"outcome" => "cancelled"
}
An individual operation that failed and was rolled back:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
}
An individual operation that itself succeeded but was rolled back due to failure of another operation:
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
}
An operation where the attempt at rollback was unsuccessful:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => false,
"rollback-failure-description" => "[DOM-9876] Some other failure message"
}
Here's an example of the response for a successful 2 step composite operation:
{
"outcome" => "success",
"result" => [
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
}
},
{
"outcome" => "success",
"result" => undefined
}
]
}
And for a failed 3 step composite operation, where the first step succeeded and the second failed, triggering cancellation of the 3rd and rollback of the others:
{
"outcome" => "failed",
"failure-description" => "[DOM-9999] Composite operation failed; see individual operation results for details",
"result" => [
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
},
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
},
{
"outcome" => "cancelled"
}
]
}
h3. Multi-Server Responses
Multi-server responses are provided by operations that target a DomainController or HostController and require the responder to apply the operation on multiple servers and aggregate their results (e.g. nearly all domain or host configuration updates.)
Multi-server operations are executed in several stages.
First, the operation may need to be applied against the authoritative configuration model maintained by the DomainController (for domain.xml confgurations) or a HostController (for a host.xml configuration). If there is a failure at this stage, the operation is automatically rolled back, with a response like this:
{
"outcome" => "failed",
"domain-failure-description" => "[DOM-3333] Failed to apply X to the domain model"
}
if the operation was addressed to the domain model, or like this:
{
"outcome" => "failed",
"host-failure-description" => "[DOM-3334] Failed to apply Y to the host model"
}
if the operation was addressed to a host model.
If the operation was addressed to the domain model, in the next stage the DomainController will ask each HostController to apply it to its local copy of the domain model. If any HostController fails to do so, the DomainController will tell all HostControllers to revert the change, and it will revert the change locally as well. The response to the client will look like this:
{
"outcome" => "failed",
"host-failure-descriptions" => {
"hostA" => "[DOM-3333] Failed to apply to the domain model",
"hostB" => "[DOM-3333] Failed to apply to the domain model"
}
}
If the preceding stages succeed, the operation will be pushed to all affected servers. If the operation is successful on all servers, the response will look like this (this operation has a void response, hence the result for each server is undefined):
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
}
}
}
The operation need not succeed on all servers in order to get an "outcome" => "success" result. All that is required is that it succeed on at least one server without the rollback policies in the rollout plan triggering a rollback on that server. (+TODO: consider something like "outcome" => "partial" for this case, and for partially successful composite operations.+) An example response in such a situation would look like this:
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
}
}
Finally, if the operation fails or is rolled back on all servers, an example response would look like this:
{
"outcome" => "failed",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
}
}
TODO: discuss some nuances related to multi-server composite operations, particularly the fact that different items in the composite may execute on different sets of servers, or only on the DC or the HC.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16354]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - JBoss Logging Tooling
by Hardy Ferentschik
Hardy Ferentschik [http://community.jboss.org/people/hardy.ferentschik] modified the document:
"JBoss Logging Tooling"
To view the document, visit: http://community.jboss.org/docs/DOC-16818
--------------------------------------------------------------
*+** Note:+* +This document is currently targeted at JBoss Logging 3.0.0 CR1 and JBoss Logging Tooling 1.0.0 Beta8-SNAPSHOT (the reason for the snapshot is a bug retrieving loggers from translated loggers)+.
**
#Why Why?
**
#How_does_it_work How does it work?
**
#Dependencies Dependencies
**
#Constraints Constraints
**
#Example_Code Example Code
**
#How_to_set_it_up_in_your_project How to set it up in your project?
***
#Maven Maven
****
#mavencompilerplugin maven-compiler-plugin
****
#mavenprocessorplugin maven-processor-plugin
***
#IDE IDE
****
#Eclipse Eclipse
****
#NetBeans NetBeans
****
#Intellij Intellij
h2. Why?
If you want to internationalize (i18n) your logging, exception messages and messages in general, then along with JBoss Logging 3.x, JBoss Logging Tools is for you. It provides an easy way to offer internationalized messages, exceptions and logger messages to your project.
With JBoss Logging Tools you write interfaces and annotate the methods with a default message. Then you or a translator will create a properties file with the translated text.
h2. How does it work?
JBoss Logging Tools uses an annotation processor to implement concrete classes of your annotated interfaces. If you have also provided translation properties files, then a new concrete class will be created extending the implementation and overriding the messages returned.
The translation properties files must exist in the same directory structure as the interface. The name of the properties file +InterfaceName.i18n_language_country_variant.properties+. For example if you have a class named +org.jboss.as.As7RocksMessages+ and you want to translate this into French you create a properties file called +As7RocksMessages.i18n_fr.properties+ in a directory +org/jboss/as+.
h2. Dependencies
* JBoss Logging 3
* tools.jar or CodeModel (which can be found here http://codemodel.java.net/ http://codemodel.java.net/)
h2. Constraints
*The following annotations are defined:*
* @org.jboss.logging.MessageBundle - This annotation is attached to an interface which is intended to be a message bundle (a generic source of translated strings; i.e. there are no logging methods on the interface). Interfaces annotated with this annotation can be instantiated via the Messages.getBundle(InterfaceName.class) method.
* @org.jboss.logging.MessageLogger - This annotation is attached to an interface which is intended to act as a translating message logger. Such interfaces may include plain bundle messages as well as logger messages. Interfaces annotated with this annotation can be instantiated via the Logger.getMessageLogger(InterfaceName.class, "category.name") method.
* @org.jboss.logging.Message - this annotation is attached to any interface method which corresponds to a message which may be translated. This includes both simple messages and log messages.
* @org.jboss.logging.LogMessage - this annotation is attached to log messages (in addition to Message above), and includes additional information such as the log level for the message.
* @org.jboss.logging.Cause - this annotation is attached to a method parameter which should be considered to be the causing java.lang.Throwable (or subclass thereof).
*Message bundle interfaces must conform to these rules:*
* The message bundle annotation may specify a project code.
* All methods defined on the message bundle interface must have a @org.jboss.logging.Message annotation present, unless the method has the same name as another method on the interface and same number of parameters (minus the cause parameter) which has the annotation present.
* All methods defined on the message bundle interface must return either java.lang.String or one of its supertypes, or java.lang.Throwable or one of its subtypes.
* All methods defined on the message bundle interface must accept a number of parameters consistent with the format string on the value attribute of the @org.jboss.logging.Message annotation. This assertion is complex to ascertain at compile-time, thus the no errors are shown at compile time.
* The @org.jboss.logging.Cause annotation may appear at most once on any given method's parameter list.
* If the method returns a java.lang.Throwable, the parameter marked as @Cause is passed in to that Throwable's constructor if it has such a parameter; if not, then it is passed in to the Throwable's initCause() method after the Throwable is constructed.
* If the method returns a java.lang.Throwable the message of the Throwable will initialized with the message from the annotation if available.
* All of the @org.jboss.logging.Message annotations found on methods on all message bundle interfaces with the same project code which specify an id must specify a unique number, INHERIT, or NONE.
* A message bundle interface may extend other message bundle interfaces.
* A message bundle interface may extend java.io.Serializable; however, doing so is superfluous as the implementation class will implement this interface regardless.
* A message bundle interface may not extend any other interfaces which do not fit the criteria specified above.
*Message logger interfaces must conform to the above rules, except:*
* A message logger interface may not specify a @org.jboss.logging.MessageBundle annotation; instead, it must specify a @org.jboss.logging.MessageLogger annotation (which also has a property for project code).
* Any method on a message logger interface may additionally specify a @org.jboss.logging.LogMessage annotation. This annotation signifies that the method is a logger method.
* All logger methods must be declared to return void.
* A logger method may have a specified log level in the level property of the @LogMessage annotation.
* If multiple methods of the same name exist, any number of them may have @LogMessage annotations. Only methods so annotated are log message methods. The rules regarding equally-named methods on message bundles continue to apply.
* Log methods with a parameter marked as @Cause will pass that parameter in to the appropriate log method as the causing exception.
* Message logger interfaces may extend other message logger interfaces in addition to the rules for message bundle interfaces.
* Message logger interfaces may extend the @org.jboss.logging.BasicLogger interface. All methods of the BasicLogger will be delegated to the logger being used for the log methods.
*Parameter count rules:*
** You should be aware parameters are counted a little differently than a normal overloaded method. The parameter count used for validation is comprised of a count of all the parameters minus the *@Cause* parameter.
h2.
Example Code
More examples to come, but for now is is a source repository of examples on how to create the interfaces for loggers and message bundles.
https://github.com/jamezp/jboss-logging-example https://github.com/jamezp/jboss-logging-example
h2. How to set it up in your project?
Using the logging tool requires minimal set-up.
h3. Maven
For a maven project you are having two options
h4. maven-compiler-plugin
In this case the JBoss Logging Tool library needs to be specified as project dependency.
...
<dependencies>
...
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-processor</artifactId>
<version>${jbossLoggingProcessorVersion}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<!-- Must be at least version 2.2 with a target of 1.6 to generate the source files in
target/generated-sources -->
<version>2.3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<showWarnings>true</showWarnings>
<!-- Optional if you wan to generate skeleton translation properties files -->
<compilerArgument>
-AgeneratedTranslationFilesPath=${project.basedir}/target/generated-translation-files
</compilerArgument>
</configuration>
</plugin>
</plugins>
</build>
...
h4. maven-processor-plugin
In this approach the +maven-processor-plugin+ is used for running the annotation processor. The +jboss-logging-processor+ dependency is now local to the plugin and the Maven bugs http://jira.codehaus.org/browse/MCOMPILER-62 MCOMPILER-62 and http://jira.codehaus.org/browse/MCOMPILER-66 MCOMPILER-66 are avoided.
...
<build>
...
<plugins>
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<version>2.0.2</version>
<executions>
<!-- Run annotation processors on src/main/java sources -->
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.jboss.logging.generator.apt.LoggingToolsProcessor</processor>
</processors>
</configuration>
</execution>
<!-- Run annotation processors on src/test/java sources -->
<execution>
<id>process-test</id>
<goals>
<goal>process-test</goal>
</goals>
<phase>generate-test-sources</phase>
<configuration>
<processors>
<processor>org.jboss.logging.generator.apt.LoggingToolsProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-processor</artifactId>
<version>${jbossLoggingProcessorVersion}</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>
...
</plugins>
</build>
...
This approach is also described on this http://in.relation.to/17636.lace blog entry on in.relation.to
h3. IDE
h4. Eclipse
When using an Eclipse project follow the instructions here http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.isv/g... (http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.isv/g...) to enable annotation processing.
h4. NetBeans
When using NetBeans as long as the library is in the class path, the annotations will automatically be processed.
h4. Intellij
Intellij IDEA offers the following documentation to enable annotation processing. http://www.jetbrains.com/idea/webhelp/compiler-annotation-processors.html (http://www.jetbrains.com/idea/webhelp/compiler-annotation-processors.html)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16818]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - Hacking on AS7
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. As a precaution, disable merge commits to your master
git config branch.master.mergeoptions --ff-only
h4. 6. Use maven (via build.sh) (make sure you use maven 3)
$ ./build.sh install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 7. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not).
Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 12+. Luckily the option set in step 5 will prevent this from happening.+
One way to not forget --rebase the rebase option is you may want to create an alias
$ git config --global alias.up "pull --rebase"
and then just use the new alias instead of pull
$ git up upstream master
One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)
h4. 8. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
You might need to say -f to force the changes. Read the note on 12 though before you do it.
h4. 9. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 10. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 11. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h4. 12. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push origin my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 13. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f origin my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
h4. 14. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
8. *Important:* Do *not* introduce a dependecy on the "*system*" module. If you need access to JDK classes which are not covered by any other dependency, use the "javax.api" module as a dependency.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add the new submodule to the modules section element of the top-level pom.xml
5. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
6. Edit build/pom.xml and add the new submodule with only group/artifact.
7. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/main/resources/modules/org/jboss/as/new-subsystem/main".
8. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
9. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
h4. Appendix D. Importing into Eclipse
The directory "ide-configs/eclipse" contains both formatter and code templates. Use these to pass the CheckStyle enforcer during the build if coding from Eclipse.
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
h4. Partial Builds
It's common when working on a particular module to need to build that module and the overall AS distribution numerous times. Doing a full AS build can be overly time consuming in this situation. The maven rf and pl options can be helpful in limiting the build to a subset of all the AS modules. See http://java.dzone.com/articles/5-maven-tips this quick introduction to both of these maven switches.
A fairly common thing is to work on a single subsystem, so you need that subsystem built, and to also have the full AS dist rebuilt so the new version of the subsystem's jar ends up in build/target. To do this, for example with the ejb3 subsystem, you would:
mvn install -pl ejb3,build
h4. IDE Integration
h5. Eclipse
Follow the steps mentioned here http://community.jboss.org/docs/DOC-16718 http://community.jboss.org/wiki/HackingAS7usingEclipse
h3.
h3. Checkstyle Errors
If you need to first verify that your changes pass the checkstyle audit, do this first.
mvn checkstyle:checkstyle
Then you can proceed with the build.
h3.
h3. Adding Subsystem Scripts
If you have a need to add a script to AS7, then definitely it should finally land inside bin/util directory. One important thing that you will need to have as part of your subsystem pom is the following plugin.
<!-- JAR -->
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>org.jboss.as.security.vault.VaultTool</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Substitute your main class.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months