# Tomcat 5.5 from ebuild -- anyone? [SOLVED]

## eealex

Hi all,

my blog (which is based on http://pebble.sourceforge.net) now is not running well after I upgraded to Tomcat 5.5 (following the Tomcat upgrade guide http://www.gentoo.org/proj/en/java/tomcat-guide.xml).  Below are some details I can tell:

What's happened: 

Yesterday after emerge --sync I found that Tomcat 5.0.x became masked, and ~x86 version of Tomcat 5.5 is out.  OK at the same time I also upgrade to use sun-jdk 1.5 as the Pebble 2.0 I mentioned requires that.  After that the Tomcat is up, application is running but I cannot save my blog...  After that I tried to downgrade to the Tomcat 5.0.28 but the same error occurs.  

Problems I observed:

No log!  I can't find my log anywhere in /var/log/tomcat-5.5

/etc/init.d/tomcat-5.5 restart always fail.  But stop... wait (2 seconds), start is OK.  This is minor problem anyway.

What I have done:

Change the /etc/conf.d/tomcat-5.5 by:

 appended this to the CLASSPATH :/var/lib/tomcat-5.5/webapps/pebble/WEB-INF/lib/log4j.jar:acegi-security-1.0.0-RC2.jar

JAVA_HOME=/opt/sun-jdk-1.5.0.07 (surely I emerged the sun-jdk)

Deployed the web application pebble.war using Tomcat manager

At least I want some log so that I can give more details about the problem actually occured... anyone gets the idea?  Thanks in advance.Last edited by eealex on Fri Jul 07, 2006 5:03 am; edited 1 time in total

----------

## dashnu

check out http://tomcat.apache.org/tomcat-5.5-doc/logging.html

tomcat uses juli now by default. 

FWIW I have the restart problem also..

----------

## eealex

Hi dashnu,

Thank you for your reply.  Anyway one stupid mistake I have made was that I should not hardcode the log4j.jar path in CLASSPATH within /etc/conf.d/tomcat-5.5.  I started over again and make the stuff work.  

Apart from the mistake I made and the restart issue the upgrade is fairly smooth now.  Anyway just assumed this topic as solved... thanks again

----------

## rem!x

 *eealex wrote:*   

> Hi all,
> 
> my blog (which is based on http://pebble.sourceforge.net) now is not running well after I upgraded to Tomcat 5.5 (following the Tomcat upgrade guide http://www.gentoo.org/proj/en/java/tomcat-guide.xml).  Below are some details I can tell:
> 
> What's happened: 
> ...

 

hi!

do you have logs now?

i have a similar log problem with log4j and my webapp after upgrading tomcat. 

its almost resolved thanks to #gentoo-java on freenode.

----------

## eealex

Hi,

Yes I got the log now.  I deleted the log4j.jar in the webapps I am deploying, and the /etc/conf.d/tomcat-5.5 is basically the default one (except changing the JAVA_HOME to sun-jdk-1.5.0.07)

----------

## dashnu

You can still use log4j if you like, keeping it in webapps level - WEBINF directory of your webapp is ok. However an issues was found in the init script causing problems with log4j.

<snip from mail-list>

Change

CLASSPATH="${CLASSPATH}:${CATALINA_HOME}/bin/bootstrap.jar:$(java-config -p commons-logging)"

to

CLASSPATH="${CLASSPATH}:${CATALINA_HOME}/bin/bootstrap.jar:${CATALINA_HOME}/bin/commons-logging-api.jar"

</snip>

Change that and you webapp should run as normal.

----------

## eealex

 *dashnu wrote:*   

> 
> 
> <snip from mail-list>
> 
> Change
> ...

 

Do you mean the /etc/conf.d/tomcat-5.5 config file?  If so the default CLASSPATH is pointing to ${CATALINA_LIBDIR}, and the ${CATALINA_LIBDIR} just refer to /usr/share/tomcat-5.5/server/lib

well all the jars inside the CATALINA_LIBDIR are just sim-link to somewhere else.. maybe a simlink pointing to common-logging-api should also be added?  I am no expert in this classpath configuration anyway.

----------

## dashnu

no I mean /etc/init.d/tomcat-5.5 .. I would leave the system level jars alone.

----------

## eealex

Thank you.  In my installation if I run the "problematic" java-config -p commons-logging:

```
$ java-config -p commons-logging

/usr/share/commons-logging/lib/commons-logging.jar:/usr/share/commons-logging/lib/commons-logging-api.jar
```

And thus this refer to common-logging-api.jar outside Tomcat directory....  seems to me that the init script wants to make use library within  /usr/share  instead of inside Tomcat.  Looks reasonable in some sense but just wonder why this creates problem....

If this is really a problem should a bug be filed?

----------

## dashnu

I worked with wltjr the guy who maintains the tomcat ebuild last night on IRC. He is going to fix it soon.

----------

## penumbra2000

Hm.  Still not fixed.  Shall I forward a patch?

----------

## kernelcowboy

 *dashnu wrote:*   

> tomcat uses juli now by default. 

 

Do we have a choice?  

I had to remove the /etc/tomcat-5.5/logging.properties file, after adding all the

log4j stuff in common/lib and classes, in order to get these to go away.

```

-rw-r--r-- 1 tomcat tomcat      0 Sep 21 10:35 manager.2006-09-21.log

-rw-r--r-- 1 tomcat tomcat      0 Sep 21 10:35 localhost.2006-09-21.log

-rw-r--r-- 1 tomcat tomcat      0 Sep 21 10:35 host-manager.2006-09-21.log

-rw-r--r-- 1 tomcat tomcat      0 Sep 21 10:35 catalina.2006-09-21.log

-rw-r--r-- 1 tomcat tomcat      0 Sep 21 10:35 admin.2006-09-21.log

```

I figured, with commons-logging, we would get log4j if it's in the classpath, or

util logging otherwise (since we are in at least a 1.4 VM)

I don't want any util logging, I'm used to log4j, and get confused quickly if there

are too many logs.

----------

## wltjr

There have been changes in Tomcat's logging. Covered in the link provided to Tomcat's site on the logging changes. Also mentoined in the Tomcat Guide. 

log4j can be used snippted from the guide

"log4j.ar MUST be in the same directory as commons-logging.jar. The lowest classloader level they should be put in is common/lib. The recommended is shared/lib, or in a specific webapp's WEB-INF/lib directory."

Beyond that just refer to the log4j section of Tomcat's doc on logging in 5.5.

The logging changes were made to the init script some time back. Where both commons-logging-api.jar (server part) was loaded on the same level as commons-logging.jar (client) which is very bad, and caused all sorts of problems. Also recently there were problems with the Catalina's temp dir not being set at runtime. Fixed recently although I doubt it pertains to any of this.

----------

