Frequently Asked Questions

Known Issues

  1. I get a NullPointerException when using Cibet JPA provider in JBoss
  2. The Cibet JPA provider could not be found in JBoss-as 7.1.1
  3. I get ClassNotFoundExceptions when using <jar-file>lib/cibet-version.jar</jar-file> with Hibernate/JBoss
  4. In Glassfish I get 'EJB5070: Exception creating stateless session bean' when a Cibet EJB method is invoked
  5. With OpenJPA I get 'You have supplied columns for "com.logitags.cibet.actuator.archive.Archive.resource.com.logitags.cibet.resource.Resource.parameters", but this mapping cannot have columns in this context.'
  6. I have an ARCHIVE and a SPRING_SECURITY / SHIRO actuator configured. However, when the business case is denied and a DeniedException is thrown, no Archive is written
  7. I have an ARCHIVE and a FOUR_EYES / SIX_EYES /TWO_MAN_RULE actuator configured. However, when the business case is postponed and a PostponedException is thrown, no Archive is written
  8. When starting the application server I get a NullPointerException in SpringSecurityActuator when defining custom aspects
  9. In an application running on Tomee the property com.logitags.cibet.persistence.provider of a JTA persistence unit is set to org.eclipse.persistence.jpa.PersistenceProvider. I get a TransactionRequiredException even if I am inside a JTA transaction. This can be observed in Tomee-plume 7.0.2 and eclipselink 2.7.0

Known Issues

I get a NullPointerException when using Cibet JPA provider in JBoss

When you define a persistence unit with com.logitags.cibet.sensor.jpa.Provider as PersistenceProvider with Hibernate as native PersistenceProvider in JBoss 7 you may get a NullPointerException when using an EntityManager from this unit:

java.lang.NullPointerException at org.hibernate.engine.transaction.internal.jta.JtaStatusHelper.getStatus(JtaStatusHelper.java:73)

This can be avoided by setting property <property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.JBossAppServerJtaPlatform" /> in the persistence unit

The Cibet JPA provider could not be found in JBoss-as 7.1.1

When you define a persistence unit with com.logitags.cibet.sensor.jpa.Provider as PersistenceProvider in JBoss-as 7.1.1 you may get the following exception during deployment:

javax.persistence.PersistenceException: JBAS011466: PersistenceProvider 'com.logitags.cibet.sensor.jpa.Provider' not found at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.lookupProvider(PersistenceUnitDeploymentProcessor.java:555) at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit(PersistenceUnitDeploymentProcessor.java:295) at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addPuService(PersistenceUnitDeploymentProcessor.java:258) at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.handleWarDeployment(PersistenceUnitDeploymentProcessor.java:194) at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deploy(PersistenceUnitDeploymentProcessor.java:118) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]

This seems to be a bug in JBoss-as 7.1.1. Change to JBoss-eap 6.3

I get ClassNotFoundExceptions when using <jar-file>lib/cibet-version.jar</jar-file> with Hibernate/JBoss

Failed to start service jboss.persistenceunit."cibetArq1.war#Cibet": org.jboss.msc.service.StartException in service jboss.persistenceunit."cibetArq1.war#Cibet": java.lang.NoClassDefFoundError: org/apache/shiro/mgt/DefaultSecurityManager

The Hibernate/JBoss PersistenceUnitService scans the cibet.jar file for JPA annotations and the JBoss classloader loads all classes that it finds in the jar. Sometimes you don't need these classes, for example the Shiro classes if you don't use Shiro.

To avoid these errors use the <class> tags instead of the <jar-file> tag:

      <class>com.logitags.cibet.actuator.archive.Archive</class>
      <class>com.logitags.cibet.actuator.archive.IntegrityCheck</class>
      <class>com.logitags.cibet.actuator.archive.IntegrityCheckResult</class>
      <class>com.logitags.cibet.actuator.dc.DcControllable</class>
      <class>com.logitags.cibet.actuator.lock.LockedObject</class>
      <class>com.logitags.cibet.resource.Resource</class>
      <class>com.logitags.cibet.resource.ResourceParameter</class>
      <class>com.logitags.cibet.core.EventResult</class>
In Glassfish I get 'EJB5070: Exception creating stateless session bean' when a Cibet EJB method is invoked

This is a bug we observed in Glassfish 3.1.2.2. See Glassfish issue 15888 and Google for more explanations. There are two workarounds:

  • add an empty beans.xml into META-INF of cibet-<version>.jar.
  • unzip cibet-<version>.jar and put the content directly into the WEB-INF/classes directory of your web application

Both workarounds may lead to ClassNotFoundExceptions because now all Cibet classes are loaded and scanned for CDI annotations. If you do not use Apache Shiro for example, there will be some Exceptions about Shiro classes not being found. These ClassNotFoundExceptions can be ignored.

With OpenJPA I get 'You have supplied columns for "com.logitags.cibet.actuator.archive.Archive.resource.com.logitags.cibet.resource.Resource.parameters", but this mapping cannot have columns in this context.'

You have to add <mapping-file>orm-openjpa.xml</mapping-file> to the cibet persistence unit in your persistence.xml. See my post in the OpenJPA mailing list for more explanations about this problem.

I have an ARCHIVE and a SPRING_SECURITY / SHIRO actuator configured. However, when the business case is denied and a DeniedException is thrown, no Archive is written

If EJB service requests are denied a DeniedEjbException is thrown which is a subclass of DeniedException. Some EJB containers do not correctly recognize this exception as an ApplicationException and roll back the transaction. To prevent this, add an ejb-jar.xml file into the META-INF directory with the following content: 

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee"
         version = "3.1"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee
           http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
  <assembly-descriptor>
    <application-exception>
      <exception-class>
        com.logitags.cibet.actuator.common.DeniedEjbException
      </exception-class>
      <rollback>false</rollback>
    </application-exception>
  </assembly-descriptor>
</ejb-jar>
I have an ARCHIVE and a FOUR_EYES / SIX_EYES /TWO_MAN_RULE actuator configured. However, when the business case is postponed and a PostponedException is thrown, no Archive is written

If EJB service requests are postponed by a dual control actuator a PostponedEjbException is thrown which is a subclass of PostponedException. Some EJB containers do not correctly recognize this exception as an ApplicationException and roll back the transaction. To prevent this, add an ejb-jar.xml file into the META-INF directory with the following content: 

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee"
         version = "3.1"
         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee
           http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
  	<assembly-descriptor>
    <application-exception>
      <exception-class>
        com.logitags.cibet.actuator.common.PostponedEjbException
      </exception-class>
      <rollback>false</rollback>
    </application-exception>
  	</assembly-descriptor>
</ejb-jar>
When starting the application server I get a NullPointerException in SpringSecurityActuator when defining custom aspects

This is a rare error observed with Glassfish but it is not excluded that it could occur also with other application servers. The situation is as follows: A Spring application that uses Cibet with custom aspects defined in an aop.xml is deployed. The Spring ContextLoaderListener is defined in web.xml as listener:

<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

The custom aspect defines a pointcut for a managed object, for example an EJB. The pointcut uses wildcards to intercept all methods of that object:

<aspectj>
	<aspects>
	  <concrete-aspect name="com.xyz.tracing.EJBAspectTest" extends="com.logitags.cibet.sensor.pojo.CustomAspect">
	  		<pointcut name="cibetIntercept" expression="target(com.logitags.cibet.helper.arquillian.EjbService) && execution(public * *(..))"/>
	  </concrete-aspect>
	</aspects>
	<weaver options="-verbose">
	</weaver>
</aspectj>

Now Glassfish uses byte code instrumentation on EJBs to add additional methods and during deployment such methods may be called. The custom aspect will be applied for the object already during registering of the managed object in the application server. Applying a Cibet custom aspect leads to initialisation of Cibet and the exception

java.lang.NullPointerException at com.logitags.cibet.actuator.springsecurity.SpringSecurityActuator.checkUrlAccessExpression(SpringSecurityActuator.java:654)

The reason is that at this point in time Spring has not been initialised and the Spring context has not been injected in SpringSecurityActuator. In Glassfish, the sequence of initialisation during startup is like this:

1. registering of aspects

2. registering of managed objects like EJBs

3. Initialisation of Spring context

It is therefore necessary to define custom aspects in a way that they are not executed before Spring has been initialised. This can be done for example by declaring more concrete methods that shall be intercepted:

<aspectj>
	<aspects>
	  <concrete-aspect name="com.xyz.tracing.EJBAspectTest" extends="com.logitags.cibet.sensor.pojo.CustomAspect">
	  		<pointcut name="cibetIntercept" expression="target(com.logitags.cibet.helper.arquillian.EjbService) && execution(public String logThis*(String))"/>
	  </concrete-aspect>
	</aspects>
	<weaver options="-verbose">
	</weaver>
</aspectj>
In an application running on Tomee the property com.logitags.cibet.persistence.provider of a JTA persistence unit is set to org.eclipse.persistence.jpa.PersistenceProvider. I get a TransactionRequiredException even if I am inside a JTA transaction. This can be observed in Tomee-plume 7.0.2 and eclipselink 2.7.0

OpenEjb auto-detects some known persistence providers like Eclipselink and provisions it with information about the application server platform. The Cibet persistence provider is not automatically detected, therefore this information is not provided and the Eclipselink provider assumes it were running on a resource-local platform

This can be avoided by setting property <property name="eclipselink.target-server" value="org.apache.openejb.jpa.integration.eclipselink.OpenEJBServerPlatform" /> in the persistence unit