[JBoss Tools] - Building JBoss Tools Documentaion
by Isaac Rooskov
Isaac Rooskov [http://community.jboss.org/people/irooskov%40redhat.com] modified the document:
"Building JBoss Tools Documentaion"
To view the document, visit: http://community.jboss.org/docs/DOC-13341
--------------------------------------------------------------
You can download a folder with a plug-in either from a Anonymous SVN (http://anonsvn.jboss.org/repos/jbosstools) or a Committer SVN (https://svn.jboss.org/repos/jbosstools) ( if you have commiter rights) repositories . In the plug-in's folder you will find a directory with documentation.This instruction explains how you can build the documentation.
h3. New Prerequisites:
Ensure you have the Maven building tool
Ensure the Nexus repository and profile as defined here: http://community.jboss.org/docs/DOC-15170 http://community.jboss.org/wiki/MavenGettingStarted-Developers are in your *+settings.xml+* file, located in your *%M2_HOME%/conf/* or *%USER_HOME%/.m2/* folder. These settings are required in order to obtain the necessary jDocbook plug-ins that are required to build the JBoss Tools documentation
h3. Previously you would have undertaken:
*+This is no longer necessary+*
2.You need to make sure you have downloaded all required files and folder from the repository:
a) Plug-in folder
b) the +*documentation*+ folder
3.Maven requires a number of plug-ins (jDocBook etc.) to generate JBoss Tools documentation and therefore you need to specify where Maven can download those plug-ins. The easiest way is to create a new profile in the Maven configuration file (*+settings.xml+*). You will find the file in *%M2_HOME%/conf/* or *%USER_HOME%/.m2/*. Open the *+settings.xml+* and add the following profile:
<profile>
<id>documentation</id>
<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
<repository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<id>repository.jboss.com</id>
<name>Jboss Repository for Maven</name>
<url>http://repository.jboss.com/maven2/</url>
<layout>default</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
</snapshots>
<id>repository.jboss.com</id>
<name>Jboss Repository for Maven</name>
<url> http://repository.jboss.com/maven2/ </url>
<layout>default</layout>
</pluginRepository>
<pluginRepository>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
<id>snapshots.jboss.org</id>
<name>Jboss Snapshots Repository for Maven</name>
<url>http://snapshots.jboss.org/maven2/</url>
<layout>default</layout>
</pluginRepository>
</pluginRepositories>
</profile>
Then you need to activate the profile if you want to use it permanently. Find the +<activeProfiles>+ tag and add this line as a child element:
<activeProfile>documentation</activeProfile>
Otherwise you should explicitly activate the profile with *-P profile_name* option while building the documentation.
h3.
h3. These steps are still required:
h3. Building Steps
So, you checked out the plug-in for which you want to build documentation and the documentation folder. And now you can proceed to building the documentation.
1.Find the +*pom.xml*+ file, that is responsible for building the documentation, in the plug-in folder you downloaded. Normally it’s located in “/docs/reference”.
2.Run *mvn clean install* or *mvn clean install -P profile_name* (if you didn't activate your profile in Maven's *+settings.xml+*) command in the folder with *+pom.xml+* to start building the documentation.
Example:
user@user-desktop:/home/user/trunk/seam/docs/reference$ mvn clean install
3.If everything is configured correctly you will see a “BUILD SUCCESSFUL” message. You will also see a generated *+target+* folder that contains the built documentation.
Example:
To open the HTML version of the “Seam Dev Tools Reference Guide” guide you need to proceed to
user@user-desktop:/home/user/trunk/seam/docs/seam/docs/reference/target/docbook/publish/en-US/html_single
and open index.html file.
h3. Documentation Profiles
There are 3 profiles that you can build documentation with:
*release* builds release documentation with “new” or “updated” markers next to the corresponding chapters and sections titles
*releaseJBDS* builds release documentation with Jboss.com styles for commercial products
> Remember to redeploy "jbosstools-jdocbook-style" and "jbosstools-docbook-xslt" if it have been changed.
> In order to redeploy you should run 'mvn deploy' from the corresponding directory. You should also have the apropriate credentials to deploy to the http://snapshots.jboss.org/maven2
*diffmk* builds documentation with markers highlighting changes comparing to the previous release version and sets “new” or “updated” markers next to the corresponding chapters and sections titles.*Note:* Please make sure that you have the master_output.xml file (normally the file can be found in \pluginName\docs\reference\en\) as a new guide may not have such file since there's nothing to compare with.
This command launches building documentation with a profile.
mvn install -Pprofile_name
By default, with no profile specified, Night Build docs are generated.
In order to build all the guide from one place you need to have JBoss Tools trunk checked out then cd to JBoss_tools_trunk/documentation/jbds-docs/ to build JBDS guides with jboss.com styles or to JBoss_tools_trunk/documentation/jboss-tools-docs to build JBoss Tools guides.
and run
mvn assembly:assembly
You can optionally use a profile in this command.
mvn assembly:assembly -Pprofile_name
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13341]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 1 month
[JBoss Cache] - Jboss node hangs frequently
by manohar Parelly
manohar Parelly [http://community.jboss.org/people/manohar.parelly] created the discussion
"Jboss node hangs frequently"
To view the discussion, visit: http://community.jboss.org/message/572561#572561
--------------------------------------------------------------
Dear All,
We have a problem in our production environment. One of our 4 jboss nodes is getting hanged frequently.
We have 4 jboss nodes clustered in 2 physical servers. They are running perfectly till 4 months back for almost 2 years.
After starting up 4 nodes one after the other they are running fine till for some period of time (sometimes 10 days, sometimes 2 days).
All of a sudden one of the jboss node is hanging and not receiving any request while other nodes are working fine. If we identify the hanging node immediately and restart the node everything works fine. Otherwise it is impacting other 3 nodes slowly and making them also to hang.
In normal case no.of threads count is not exceeding 200 in any node. But when it hangs, it is showing more than 500 threads in Thread dump.
*Thread dump I have attached. Please check.*
We found below exception in our server.log file just before jboss node goes down. Please check below error:
Please let me know if you need any more information. Please give your suggestions to resolve the issue.
java.lang.RuntimeException: JBossCacheService: exception occurred in cache get after retry ...
at org.jboss.web.tomcat.service.session.JBossCacheWrapper.get(JBossCacheWrapper.java:94)
at org.jboss.web.tomcat.service.session.JBossCacheService.loadSession(JBossCacheService.java:251)
at org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:1010)
at org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:782)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2283)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:99)
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:87)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/JSESSION/localhost/atheebweb/MhPmOOs88X4+gQY0qxzIHA**, caller=GlobalTransaction:<172.16.64.21:7811>:678309, lock=write owner=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads] (activeReaders=0, activeWriter=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:500)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:381)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:309)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:183)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5877)
at org.jboss.cache.TreeCache.get(TreeCache.java:3641)
at org.jboss.cache.TreeCache.get(TreeCache.java:3622)
at org.jboss.cache.TreeCache.get(TreeCache.java:3418)
at sun.reflect.GeneratedMethodAccessor143.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy443.get(Unknown Source)
at org.jboss.web.tomcat.service.session.JBossCacheWrapper.get(JBossCacheWrapper.java:78)
... 17 more
Caused by: org.jboss.cache.lock.TimeoutException: read lock for /JSESSION/localhost/atheebweb/MhPmOOs88X4+gQY0qxzIHA** could not be acquired by GlobalTransaction:<172.16.64.21:7811>:678309 after 15000 ms. Locks: Read lock owners: []
Write lock owner: Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads]
, lock info: write owner=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads] (activeReaders=0, activeWriter=Thread[IncomingMessageHandler (channel=Tomcat-AtheebWeb),5,JGroups threads], waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:262)
at org.jboss.cache.Node.acquireReadLock(Node.java:512)
at org.jboss.cache.Node.acquire(Node.java:474)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572561#572561]
Start a new discussion in JBoss Cache at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[EJB3] - Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1"
To view the discussion, visit: http://community.jboss.org/message/572533#572533
--------------------------------------------------------------
> aravind kopparthi wrote:
>
> thanks for the comments. but in my example Singleton is not trying to do any WRITES is it? all the business logic is in SLSBean that this singleton delegates to and that to slsb call that singleton calls is @Asynchronous slbs.process().
The EJB3 container has no way to know what you have in your impl of that method. Unless you explicitly specify as a READ lock, it's by default treated for WRITE lock.
> aravind kopparthi wrote:
>
> my question what is that i need to configure in the interseptors some where where SLSB injected in Singleton are not treaded like regular beans and handle with multiple pool instances when ever a method is invoked by the container ( timeout) or by the calller.
Just mark that timeout method on the singleton to be READ lock type:
import javax.ejb.Lock;
import javax.ejb.LockType;
@Lock(LockType.READ)
@Timeout
public void process(javax.ejb.Timer timer) {
...
If you want READ lock to apply to all business methods in that singleton bean, then specify that annotation on the EJB bean class level.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572533#572533]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[EJB3] - Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion
"Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1"
To view the discussion, visit: http://community.jboss.org/message/572509#572509
--------------------------------------------------------------
The EJB3.1 spec says (for singleton bean concurrency):
> If the concurrency locking attribute is not specified, it is assumed to be Lock(WRITE). The absence of a concurrency attribute specification on the bean class is equivalent to the specification of Lock(WRITE)on the bean class.
>
Furthermore, the spec says:
> If the container invokes a method associated with a Read lock, any number of other concurrent invocations on Read methods are allowed to access the bean instance simultaneously.
>
> If the container invokes a method associated with a Write lock, no other concurrent invocations will be allowed to proceed until the initial Write method’s processing completes. A concurrent access attempt that is not allowed to proceed due to locking is blocked until it can make forward progress.
Your @Singleton bean doesn't specify any explicit @Lock. So it's treated by default as WRITE lock and that explains the behaviour you are seeing.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/572509#572509]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[JBoss Messaging] - recovering from invalid messages, selectively deleting from db
by Tim Coninx
Tim Coninx [http://community.jboss.org/people/timconinxrvp] created the discussion
"recovering from invalid messages, selectively deleting from db"
To view the discussion, visit: http://community.jboss.org/message/567157#567157
--------------------------------------------------------------
We use Jboss 5.0 with an oracle db and a standard jboss-messaging deployment.
Irregularly, a queue is unable to start and (therefore) bind itself in JNDI. This has something to do with (I think) corrupt messages which prevent the queue from starting: the exception we see is
java.sql.SQLException: Invalid column index
The error happens very irregularly (like I said), and we haven't been able to really reproduce it yet. However, it seems to happen when a jboss server is killed dirty while messages are being processed.
Deleting all messages directly in the db (delete from jbm_msg / delete from jbm_msg_ref) resolves the problem, but unfortunately it also removes other queue's messages.
So the question is, either:
- is there a way to sql-delete only the offending queue's messages, or
- is there a more elegant way to recover from corrupt messages (remember, the queue does not even start)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/567157#567157]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month