Using is JBoss is quite simple, in some ways simpler than Tomcat alone. Essentially, all you need to do is expand the igroupcal.war file into the deploy directory, and create the users and roles files. Create an igroupcal.war directory in your deploy directory. If you are running on MacOS X, this will be something like where you would replace default with the setting chosen for "Configuration Type" in the "Application Server" preference pane of the Server Manager.

First of all, there is little chance that you will be able to use the on-the-fly mode (emmarun) with a full-blown J2EE container. The reason lies in the fact that many J2EE features require specialized classloading that will happen outside of EMMA instrumenting classloader. The server might run fine, but you will likely get no coverage data. Thus, the correct procedure is to instrument your classes prior to deployment (offline mode).

michaelyaakoby reports: I'm trying to launch a J2EE client (JBoss) using Web Start. I already figured out how to provide the security settings by publishing the auth.conf and app.policy files on the web server and by handing over the URLs with the java.security.policy and java.security.auth.login.config properties. However, when the client tries to get hold of the EJB (using the home interface create() method, I end up with the exception below: java.security.

Answer: No, the JNDI, deploy descriptor, connection pool and other settings in JBoss are different with other commercial application servers like WebLogic.

You can make any calendar you like private by using private as the last part of the base URL in the publish dialog. For example, say your calendar is "Birthdays" - for normal publication from iCal you'd use the calendar name If you were using some other publishing tool, you might have to enter that full URL yourself - in iCal it's not necessary.

TopLink Essentials, like JBoss's Hibernate product, is an open source object-relational persistence framework or layer used in Java applications. While both products strive to deliver a non-intrusive highly flexible and performant solution there are some key differences. TopLink Essentials, derived from Oracle TopLink has been in production Java applications scaling to large deployments and high transaction volumes for over a decade.

JBoss Cache is a replicated and transactional cache. It is replicated since multiple JBoss Cache instances can be distributed (either within the same JVM or across several JVMs whether they reside on the same machine or on different machines on a network) and data is replicated across the whole group. It is transactional because a user can configure a JTA compliant transaction manager and make any cache interaction transactional.

Author: Luigi Viggiano (http://www.jguru.com/guru/viewbio.jsp?EID=101985) Question originally posed by Eng Fong Lau (http://www.jguru.com/guru/viewbio.jsp?EID=5348 Most of this information comes from the official JBoss site at http://www.jboss.org/business/jboss-tomcat.html First of all, JBoss has been tested with tomcat 3.2.1, newer version shall be configured in similar way I think. Tomcat libs must be in classpath; then edit JBOSS_HOME/conf/default/jboss.

You need SwiftMQ 3.x plus the JMS XA/ASF Swiftlet. A detailed description of the required changes to the JBoss config files is provided in the JMS XA/ASF... SwiftMQ has a local authentication design where each router in a router network has to be a trusted router of the network. Each router serves as en...

JBoss Cache has an active community of developers and contributors. The project was founded by Bela Ban and is currently led by Manik Surtani. Jason Greene is the lead for the PojoCache subsystem, and other contributors both past and present include Ben Wang, Harald Gliebe, Brian Stansberry, Galder Zamarreno and Elias Ross.

The JBoss Cache product download page has prebuilt binaries as well as source distributions. You can also grab snapshots from the JBoss CVS repository (see this wiki page ) - the module name is JBossCache

Accessing the JBoss Cache MBean is just like accessing any JBoss MBean. Here is a code snippet: import org.jboss.mx.util.MBeanServerLocator; import org.jboss.mx.util.MBeanProxyExt; import org.jboss.cache.TreeCacheMBean; import javax.management.MBeanServer; ... MBeanServer server; TreeCacheMBean cache; public init() throws Exception { try { server = MBeanServerLocator.locateJBoss(); cache = (TreeCacheMBean) MBeanProxyExt.create(TreeCacheMBean.class, "jboss.

You can configure the JBoss Cache through a configuration xml file or programmatically using a org.jboss.cache.config.Configuration object, passed in to the org.jboss.cache.CacheFactory instance.

No, although it is also on our to do list. Our internal implementation does use a procedure similar to 2PC to coordinate a transactions among different instances, but JBoss Cache is not an XA resource.

Yes, using a JMX console such as the one shipped with JBoss AS or Java 5's jconsole utility. See the chapter titled Management Information in the JBoss Cache user guide for more details.

of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of the benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is baselined on Java 5, there was no need to provide these benefits separately. Not right now. JBoss Cache does not support partitioning that a user can configure to have different set of data residing on different cache instances while still participating as a replication group.

Of course! Even though JBoss Cache comes integrated with JBoss Application Server as an MBean service, it can also be run standalone, in any Java EE server such as BEA WebLogic, IBM Websphere or Tomcat. It can also run in a standalone Java process, completely outside of an application server. See the user guide for more details.

JBoss has a "Certified JBoss Developer" as its basic level. Additional levels are availalble. See http://www.jboss.org/services/certification for more...

JBoss' unified class loader can cause problems with conflicting Jar files. One issue commonly encountered is with log4j, which is part of both JBoss and Grails. This can be resolved by removing log4j.jar from your deployed .war file or using scoped classloading (with some caveats). Ideally you wouldn't want to remove the log4j file from your deployment as this requires some additional work and will break many automated deployment/testing processes.