1 Reply Latest reply on Apr 14, 2005 4:26 PM by adrian.brock

    Avoiding FAQ posts by providing a NAGGING log

      Do you think it would be a good idea to provide a "NAGGING" log?

      The idea being that it will log warnings about potentially stupid configurations
      or feature uses
      to a separate log that can be turned off if people really know what they are doing.

      e.g. The follow code points out the commonly seen misconfiguration
      read-only + commit-option B. i.e. The data is reloaded on every finegrained
      invocation on the entity bean.

      NOTE: This one is a difficult example, since such a configuration works just fine
      with the DTO pattern and getDTO() is the only invocation on the ejb for each transaction.

      Index: EntitySynchronizationInterceptor.java
      ===================================================================
      RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInterceptor.java,v
      retrieving revision 1.86
      diff -u -r1.86 EntitySynchronizationInterceptor.java
      --- EntitySynchronizationInterceptor.java 10 Aug 2004 17:12:58 -0000 1.86
      +++ EntitySynchronizationInterceptor.java 14 Apr 2005 20:16:30 -0000
      @@ -21,6 +21,7 @@
       import org.jboss.ejb.EntityEnterpriseContext;
       import org.jboss.ejb.GlobalTxEntityMap;
       import org.jboss.invocation.Invocation;
      +import org.jboss.logging.Logger;
       import org.jboss.metadata.ConfigurationMetaData;
       import org.jboss.util.NestedRuntimeException;
      
      @@ -45,6 +46,8 @@
       public class EntitySynchronizationInterceptor
       extends AbstractInterceptor
       {
      + private static final Logger nag = Logger.getLogger("org.jboss.nagging");
      +
       /**
       * The variable <code>vcrThread</code> holds the valid context refresher thread for
       * this interceptor, so it may be shut down in stop.
      @@ -66,6 +69,9 @@
       */
       protected EntityContainer container;
      
      + /** Whether we have warned about non performant synchronization */
      + private boolean warnedSynchronizationFAQ = false;
      +
       public Container getContainer()
       {
       return container;
      @@ -296,11 +302,13 @@
       // Keep instance active, but invalidate state
       case ConfigurationMetaData.B_COMMIT_OPTION:
       // Invalidate state (there might be other points of entry)
      + logSynchronizationFAQ();
       ctx.setValid(false);
       break;
      
       // Invalidate everything AND Passivate instance
       case ConfigurationMetaData.C_COMMIT_OPTION:
      + logSynchronizationFAQ();
       try
       {
      @@ -349,11 +357,13 @@
       // Keep instance active, but invalidate state
       case ConfigurationMetaData.B_COMMIT_OPTION:
       // Invalidate state (there might be other points of entry)
      + logSynchronizationFAQ();
       ctx.setValid(false);
       break;
      
       // Invalidate everything AND Passivate instance
       case ConfigurationMetaData.C_COMMIT_OPTION:
      + logSynchronizationFAQ();
       try
       {
       // Do not call release if getId() is null. This means that
      @@ -384,7 +394,19 @@
       }
       }
       }
      -
      +
      + private void logSynchronizationFAQ()
      + {
      + if (warnedSynchronizationFAQ == false)
      + {
      + warnedSynchronizationFAQ = true;
      + nag.warn("The use of read-only or lack of a transaction and not using a cache (commit-option B/C) " +
      + "will mean reloading of data on every entity bean invocation! ejb-name="
      + + container.getBeanMetaData().getEjbName());
      +
      + }
      + }
      +
       protected class InstanceSynchronization
       implements Synchronization
       {