topic Error in JBoss in Alfresco Archive

Error in JBoss

rdanner — Sun, 22 Jan 2006 07:28:22 GMT

As much as I hate to post about bugs and stack traces I have had about enough of this one so Im wondering if you guys already know the answer.I have a war built on 1.1.2 which deploys perfectly in tomcat but dies in JBoss.I assume there is something different about the configuration between a jbo

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 08:23:36 GMT

As much as I hate to post about bugs and stack traces …ops:

How does this work out?


    public synchronized void begin() throws NotSupportedException, SystemException
    {
        // make sure that the status and info align - the result may or may not be null
        TransactionInfo txnInfo = getTransactionInfo();
        if (internalStatus != Status.STATUS_NO_TRANSACTION)
        {
            throw new NotSupportedException("The UserTransaction may not be reused");
        }
        
        // begin a transaction
        internalTxnInfo = createTransactionIfNecessary(null, null);  // super class will just pass nulls back to us
        internalStatus = Status.STATUS_ACTIVE;
        threadId = Thread.currentThread().getId();
        
        // done
        if (logger.isDebugEnabled())
        {
            logger.debug("Began user transaction: " + this);
        }
    }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

calls


protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
      // If the transaction attribute is null, the method is non-transactional.
      final TransactionAttribute sourceAttr =
            this.transactionAttributeSource.getTransactionAttribute(method, targetClass);
      TransactionAttribute txAttr = sourceAttr;

      // If no name specified, apply method identification as transaction name.
      if (txAttr != null && txAttr.getName() == null) {
         final String name = methodIdentification(method);
         txAttr = new DelegatingTransactionAttribute(sourceAttr) {
            public String getName() {
               return name;
            }
         };
      }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

which calls


   protected String methodIdentification(Method method) {
      return ClassUtils.getQualifiedMethodName(method);
   }
‍‍‍‍‍

which performs the assert on method which is null from the beginning and throws the exception


        // begin a transaction
        internalTxnInfo = createTransactionIfNecessary(null, null);  // super 

doest return null as the comment suggests; it blows up
‍‍‍‍‍‍

I am going to go back and trace this in tomcat since the behavior is different (ie tomcat loads just fine). I must be picking up the wrong implementation of something somewhere. Its 3:30 am here so i am probably seeing things :shock:

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 09:27:55 GMT

As much as I hate to post about bugs and stack traces …ops:

How does this work out?…..

this code evaluate in opposing ways in the two environments
Inside springs TransactionApectSupport. createTransactionIfNecessary


      TransactionInfo txInfo = new TransactionInfo(txAttr, method);
      if (txAttr != null) {
         // We need a transaction for this method
         if (logger.isDebugEnabled()) {
            logger.debug("Getting transaction for " + txInfo.joinpointIdentification());
         }

         // The transaction manager will flag an error if an incompatible tx already exists
         txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
      }
      else {
         // The TransactionInfo.hasTransaction() method will return
         // false. We created it only to preserve the integrity of
         // the ThreadLocal stack maintained in this class.
         if (logger.isDebugEnabled())
            logger.debug("Don't need to create transaction for [" + methodIdentification(method) +
                  "]: this method isn't transactional");
      }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

where


   TransactionInfo txInfo = new TransactionInfo(txAttr, method);
‍‍‍

returns null in JBOSS and not null in tomcat.

In tomcat there is a lot of interaction from the spring/hibernate classes.
in JBOSS there is not
In both cases the transaction manager is resolving a reference to the HibernateTransactionManager.

Certainly this is a configuration issue and looking inward as I am doing (clue searching) is the wrong approach to solving this bug. The AOP and bean factory reflections code is sooo much fun to debug HAHA

One thing we might want to do is put a try catch around the call


 internalTxnInfo = createTransactionIfNecessary(null, null);  // super class will just pass nulls back to us
‍‍‍

since we will most certainly blow up later for a different reason (we are not really in a transaction) we should test for that right after the call and throw a more intellegent error.

In terms of solving my issue I am not sure I am much further along but IOnce I figure it out I will go ahead and submit the code which gives a better error message rather then letting spring throw out some low level assert garabage.

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 09:33:09 GMT

What version of spring are you using? The code I downloaded from sourceforge is for version 1.2.6 and is not the same as what I am running (simular but different) so Its obnoxious stepping in to code and walking over comments rather then execution path

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 11:05:18 GMT

What version of spring are you using? The code I downloaded from sourceforge is for version 1.2.6 and is not the same as what I am running (simular but different) so Its obnoxious stepping in to code and walking over comments rather then execution path

I Think I am about to start using going on my postal spree… for the play by play here…. I am looking at a debug log message that throws the error

that is… if debugging is on… even tomcat explodes. As usual I find myself in a situation where it is some poor engineering practice which leads to my headache. Moral of the story… its not the same unless it is exactly the same, take nothing for granted. Science and it's application is exact or not at all.

UGH!

ok guys here is the line with context
Within springs TransactionAspectSupport.createTransactionIfNecessary


      TransactionInfo txInfo = new TransactionInfo(txAttr, method);
      if (txAttr != null) {
         // We need a transaction for this method
         if (logger.isDebugEnabled()) {
            logger.debug("Getting transaction for " + txInfo.joinpointIdentification());
         }
‍‍‍‍‍‍‍‍

actually its


      TransactionInfo txInfo = new TransactionInfo(txAttr, method);
      if (txAttr != null) {
         // We need a transaction for this method
         if (logger.isDebugEnabled()) {
            logger.debug("Getting transaction for " + txInfo.joinpointIdentification());
         }
‍‍‍‍‍‍‍‍

This occurs on the third visit to this message during startup where the member "method" is null in TransactionAspectSupport

My bad engineering is at fault for my troubles so I will take the oppertunity to drag spring down with me

That log message is a terrible engineering practice. concatinating active functions to strings for logging purposes is playing with fire and should never be done.

I hope I can lower the log level and go on my merry way or i'll just go insane … gunna go take a nap then get back to work.

Cheers
-R

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 11:17:27 GMT

The best part is that now that I am thinking about this.. I think one of our guys was through this with you guys or at least there was something to do with jboss / alfresco and a log4j setting

not sure if is the same issue but if it is…. it figures :?

Re: Error in JBoss

rdanner — Sun, 22 Jan 2006 11:53:29 GMT

The best part is that now that I am thinking about this.. I think one of our guys was through this with you guys or at least there was something to do with jboss / alfresco and a log4j setting

not sure if is the same issue but if it is…. it figures :?

Yes I believe this is the same issue ops:
Well If you are looking for the solution to this issue here it is :

The solution is to alter the log4j.xml in your conf directory (most likely server/default/conf

to be


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<!– ===================================================================== –>
<!–                                                                       –>
<!–  Log4j Configuration                                                  –>
<!–                                                                       –>
<!– ===================================================================== –>

<!– $Id: log4j.xml,v 1.26.2.2 2005/03/02 14:52:20 tdiesler Exp $ –>

<!–
   | For more configuration infromation and examples see the Jakarta Log4j
   | owebsite: http://jakarta.apache.org/log4j
 –>

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">

   <!– ================================= –>
   <!– Preserve messages in a local file –>
   <!– ================================= –>

   <!– A time/date based rolling appender –>
   <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.home.dir}/log/server.log"/>
      <param name="Append" value="false"/>

      <!– Rollover at midnight each day –>
      <param name="DatePattern" value="'.'yyyy-MM-dd"/>

      <!– Rollover at the top of each hour
      <param name="DatePattern" value="'.'yyyy-MM-dd-HH"/>
      –>

      <layout class="org.apache.log4j.PatternLayout">
         <!– The default pattern: Date Priority [Category] Message\n –>
         <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>

         <!– The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
         <param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
          –>
      </layout>
   </appender>

   <!– A size based file rolling appender
   <appender name="FILE" class="org.jboss.logging.appender.RollingFileAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="File" value="${jboss.server.home.dir}/log/server.log"/>
     <param name="Append" value="false"/>
     <param name="MaxFileSize" value="500KB"/>
     <param name="MaxBackupIndex" value="1"/>

     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
     </layout>       
   </appender>
   –>

   <!– ============================== –>
   <!– Append messages to the console –>
   <!– ============================== –>

   <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="Target" value="System.out"/>
      <param name="Threshold" value="INFO"/>

      <layout class="org.apache.log4j.PatternLayout">
         <!– The default pattern: Date Priority [Category] Message\n –>
         <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
      </layout>
   </appender>

   <!– ====================== –>
   <!– More Appender examples –>
   <!– ====================== –>

   <!– Buffer events and log them asynchronously
   <appender name="ASYNC" class="org.apache.log4j.AsyncAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <appender-ref ref="FILE"/>
     <appender-ref ref="CONSOLE"/>
     <appender-ref ref="SMTP"/>
   </appender>
   –>

   <!– EMail events to an administrator
   <appender name="SMTP" class="org.apache.log4j.net.SMTPAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="Threshold" value="ERROR"/>
     <param name="To" value="admin@myhost.domain.com"/>
     <param name="From" value="nobody@myhost.domain.com"/>
     <param name="Subject" value="JBoss Sever Errors"/>
     <param name="SMTPHost" value="localhost"/>
     <param name="BufferSize" value="10"/>
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="[%d{ABSOLUTE},%c{1}] %m%n"/>
     </layout>
   </appender>
   –>

   <!– Syslog events
   <appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="Facility" value="LOCAL7"/>
     <param name="FacilityPrinting" value="true"/>
     <param name="SyslogHost" value="localhost"/>
   </appender>
   –>

   <!– Log events to JMS (requires a topic to be created)
   <appender name="JMS" class="org.apache.log4j.net.JMSAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="Threshold" value="ERROR"/>
     <param name="TopicConnectionFactoryBindingName" value="java:/ConnectionFactory"/>
     <param name="TopicBindingName" value="topic/MyErrorsTopic"/>
   </appender>
   –>

   <!– Log events through SNMP
   <appender name="TRAP_LOG" class="org.apache.log4j.ext.SNMPTrapAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="ImplementationClassName" value="org.apache.log4j.ext.JoeSNMPTrapSender"/>
     <param name="ManagementHost" value="127.0.0.1"/>
     <param name="ManagementHostTrapListenPort" value="162"/>
     <param name="EnterpriseOID" value="1.3.6.1.4.1.24.0"/>
     <param name="LocalIPAddress" value="127.0.0.1"/>
     <param name="LocalTrapSendPort" value="161"/>
     <param name="GenericTrapType" value="6"/>
     <param name="SpecificTrapType" value="12345678"/>
     <param name="CommunityString" value="public"/>
     <param name="ForwardStackTraceWithTrap" value="true"/>
     <param name="Threshold" value="DEBUG"/>
     <param name="ApplicationTrapOID" value="1.3.6.1.4.1.24.12.10.22.64"/>
     <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d,%p,[%t],[%c],%m%n"/>
     </layout>
   </appender>
   –>

   <!– ================ –>
   <!– Limit categories –>
   <!– ================ –>

   <!– Limit the org.apache category to INFO as its DEBUG is verbose –>
   <category name="org.jboss.system.server.Server">
      <priority value="INFO"/>
   </category>
   <category name="org.apache.log4j.Log4jService$URLWatchTimerTask">
      <priority value="INFO"/>
   </category>

   <!–
   <category name="org.alfresco">
      <priority value="INFO"/>
   </category>
   –>

   <!– Decrease the priority threshold for the org.jboss.varia category
   <category name="org.jboss.varia">
     <priority value="DEBUG"/>
   </category>
   –>

   <!– Show the evolution of the DataSource pool in the logs [inUse/Available/Max]
   <category name="org.jboss.resource.connectionmanager.JBossManagedConnectionPool">
     <priority value="TRACE" class="org.jboss.logging.XLevel"/>
   </category>
   –>

   <!–
      | An example of enabling the custom TRACE level priority that is used
      | by the JBoss internals to diagnose low level details. This example
      | turns on TRACE level msgs for the org.jboss.ejb.plugins package and its
      | subpackages. This will produce A LOT of logging output.
   <category name="org.jboss.system">
     <priority value="TRACE" class="org.jboss.logging.XLevel"/>
   </category>
   <category name="org.jboss.ejb.plugins">
     <priority value="TRACE" class="org.jboss.logging.XLevel"/>
   </category>
   –>
  
   <!–
       | Logs these events to SNMP:
           - server starts/stops
           - cluster evolution (node death/startup)
           - When an EJB archive is deployed (and associated verified messages)
           - When an EAR archive is deployed
          
   <category name="org.jboss.system.server.Server">
     <priority value="INFO" />
     <appender-ref ref="TRAP_LOG"/>
   </category>
  
   <category name="org.jboss.ha.framework.interfaces.HAPartition.lifecycle">
     <priority value="INFO" />
     <appender-ref ref="TRAP_LOG"/>
   </category>

   <category name="org.jboss.deployment.MainDeployer">
     <priority value="ERROR" />
     <appender-ref ref="TRAP_LOG"/>
   </category>
   
   <category name="org.jboss.ejb.EJBDeployer">
     <priority value="INFO" />
     <appender-ref ref="TRAP_LOG"/>
   </category>
   
   <category name="org.jboss.deployment.EARDeployer">
     <priority value="INFO" />
     <appender-ref ref="TRAP_LOG"/>
   </category>
   
  
   –>


   <!– ======================= –>
   <!– Setup the Root category –>
   <!– ======================= –>

   <root>
      <priority value="ERROR"/>
      <appender-ref ref="CONSOLE"/>
      <appender-ref ref="FILE"/>
   </root>

   <!– Clustering logging –>
   <!– Uncomment the following to redirect the org.jgroups and
      org.jboss.ha categories to a cluster.log file.

   <appender name="CLUSTER" class="org.jboss.logging.appender.RollingFileAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="File" value="${jboss.server.home.dir}/log/cluster.log"/>
     <param name="Append" value="false"/>
     <param name="MaxFileSize" value="500KB"/>
     <param name="MaxBackupIndex" value="1"/>

     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
     </layout>
   </appender>
   <category name="org.jgroups">
     <priority value="DEBUG" />
     <appender-ref ref="CLUSTER"/>
   </category>
   <category name="org.jboss.ha">
     <priority value="DEBUG" />
     <appender-ref ref="CLUSTER"/>
   </category>
   –>

</log4j:configuration>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

this will shut jboss up (it will stop logging debug) and you wont crash because the problematic line of code wont be executed.

This is the short term fix. The long term fix is a spring fix since it is a bug in a spring class. It's already probably taken care of for all I know.

Another interesting thing I learned through this execise is that alfresco does not work with the 1.2.6 version of the spring library. I notices that alfresco made a fix to a spring class (patch). This could be the issue but I have no idea on that. Out of the box the spring 1.2.6 jar will cause alfresco fail to initialize during startup when the beans being created.

Well I am irratated at Spring for abusing the log messages with active functions that cause exceptions and embarrased that i spent all night looking at a bug that Alfresco helped on of our guys solve already.

I am also embarrased that apparently I held an entire conversation with myself on this forum hahaha…

I didnt see anything in our wikki on it so I updated it haha… Wait till danny hears about this.

Thanks all, i'm out!
-R