Tech Notes – Page 79 – Kev's Development Toolbox

July 25, 2012

DeploymentScanner timeouts on OpenShift JBoss AS7

I haven’t seen this error often on the hosted OpenShift service (only occasionally when there’d been a system update and your app doesn’t redeploy correctly once restarted), but running OpenShift Origin locally I was seeing this consistently trying to deploy a new application:

2012/07/25 15:00:24,158 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [60 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment.
2012/07/25 15:00:24,160 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ROOT.war" was rolled back with failure message Operation cancelled

To increase the deployment scanner’s timeout setting, edit your project’s .openshift/config/standalone.xml, and find the deployment-scanner element:

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
            <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" />
        </subsystem>

…and then add this attribute to <deployment-scanner> :

deployment-timeout="1200"

The XSD schema for this element says the default value is 600 second, but the error above says it’s timing out after 60 seconds. Assuming the default value is 600, I doubled it, and this fixed my timeout issues.

July 25, 2012

Controlling Services on Fedora

Fedora uses the servicectl utility to enable/disable and control services.

To use:

sudo servicectl status servicename
sudo servicectl enable/disable servicename
sudo servicectl start|stop servicename

July 10, 2012

Configuring an @MessageDriven bean on JBoss AS7

If you forget to add the destination property to the activationConfig for an MDB, when deploying to JBoss AS7 you’ll get this NullPointerException. Would be better if it told you what required property was missing:

16:30:29,007 WARN  [org.hornetq.ra.inflow.HornetQActivation] (default-short-running-threads-threads - 1) Failure in HornetQ activation org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@6ba59338 destination=null destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): java.lang.NullPointerException
    at javax.naming.NameImpl.<init>(NameImpl.java:281) [rt.jar:1.7.0_04]
    at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_04]
    at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
    at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:440)
    at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:213)
    at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_04]
    at org.hornetq.ra.Util.lookup(Util.java:174) [hornetq-ra-2.2.11.Final.jar:]
    at org.hornetq.ra.inflow.HornetQActivation.setupDestination(HornetQActivation.java:454) [hornetq-ra-2.2.11.Final.jar:]
    at org.hornetq.ra.inflow.HornetQActivation.setup(HornetQActivation.java:287) [hornetq-ra-2.2.11.Final.jar:]
    at org.hornetq.ra.inflow.HornetQActivation$SetupActivation.run(HornetQActivation.java:605) [hornetq-ra-2.2.11.Final.jar:]
    at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:212)
    at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
    at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
    at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
    at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_04]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Here’s a correctly configured MDB:

@MessageDriven(mappedName = "queue/QueueName", activationConfig = {
        @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/queueName") })
public class QueueListener implements MessageListener {
...
}

June 21, 2012

Location of JPA persistence.xml to auto find entities

I’m working on some example code to show different configuration options and approaches for using Hibernate with JPA. I just noticed that the location of the /META-INF/persistence.xml file is critical to allow Hibernate to auto-locate your annotated entities.

In order for the auto location to work (to avoid having to explicitly list annotated entities in your persistence.xml or hibernate.cfg.xml files), the persistence.xml file must be bundled in the same jar as the entities. If you move the file elsewhere, then the entities are not found, even if they are in the classpath. To workaround this, if you do need to put the persistence.xml file in a different location, use the <mapping> element to explicitly declare the entities.