Confusing stack trace on EJB deployment for missing optional method attribute <transaction-timeout>

This bug is not critical, but unnecessary stack traces at DEBUG level make the log look untidy and make both system administrators and developers spend precious time investigating a problem that doesn't exist.

On deployment of my EJBs in JBoss 3.2.6 NumberFormatExceptions are logged repeatedly with stack traces on DEBUG level:

2005-01-19 16:23:21,765 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/home/jpm/jboss/jboss-3.2.6/
server/myproject/deploy/myproject-ejb.jar
2005-01-19 16:23:21,766 DEBUG [org.jboss.ejb.EJBDeployer] create, myproject-ejb.jar
2005-01-19 16:23:27,172 DEBUG [org.jboss.metadata.MetaData] Ignoring transaction-timeout 'null'
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:436)
at java.lang.Integer.parseInt(Integer.java:518)
at org.jboss.metadata.BeanMetaData.importJbossXml(BeanMetaData.java:790)
at org.jboss.metadata.EntityMetaData.importJbossXml(EntityMetaData.java:341)
at org.jboss.metadata.ApplicationMetaData.importJbossXml(ApplicationMetaData.java:729)
at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:175)
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:462)
...

A relevant piece of the (XDoclet-generated) jboss.xml contained in the .jar file looks like:

<entity>
<ejb-name>MyEntity</ejb-name>
<jndi-name>ejb/myproject/MyEntity</jndi-name>
<local-jndi-name>ejb/myproject/MyEntity</local-jndi-name>

<method-attributes>
<method>
<method-name>getId</method-name>
<read-only>true</read-only>
</method>
<method>
<method-name>getStatus</method-name>
<read-only>true</read-only>
</method>
...
</method-attributes>
</entity>
...

So, my method-attributes don't contain the optional <transaction-timeout> element, which should be perfectly legal (it was in JBoss 3.2.1 anyway).

The following piece of JBoss code (from BeanMetaData.java, from line 787) appears to be the culprit:

String txTimeout = getOptionalChildContent(maNode, "transaction-timeout");
try

{ ma.txTimeout = Integer.parseInt(txTimeout); }

catch (Exception ignore)

{ log.debug("Ignoring transaction-timeout '" + txTimeout + "'", ignore); }

I suggest that txTimeout should be tested for a null value before attempting to parse it as integer. Apart from that, no stack trace should be logged for something that can be legally ignored.