re: Exception thrown at startup (default context)

Hi Chris,

I tested this out on Tomcat 4.1.18 by dropping the log4j-1.2.7.jar into the
WEB-INF/lib directory of the securityfilter-example app and deploying that
in the root context.(*)(#) I didn't see any errors when the server started
up and the app seemed to work fine.

I have not used log4j before, so perhaps I missed something in the setup. Do
I need to do anything besides dropping the jar into my app's WEB-INF/lib
directory?

Another possible explanation for why it worked for me is that I was using
Tomcat 4.1.18 rather than 4.1.8. I tried to find a 4.1.8 distribution to
install, but I couldn't find one. That doesn't seem to be one of the
releases they retained on the download site. 4.1.24 is out now, but I
haven't tried that yet. Could you try installing 4.1.18 or 4.1.24 to see if
that fixes the problem?

I did a web search and found something related to a VerifyError that
suggested that you might get this if you compile and run with different
versions of the JDK. I used Sun's J2SDK 1.4.1_01 to compile the last release
of securityfilter, and I was testing with a version compiled with 1.4.1_02.
I used the log4j-1.2.7.jar file as-is from the log4j distribution and ran my
Tomcat server with 1.4.1_02. This seems like an odd possibility, but what
version of the J2SDK were you using to run Tomcat?

-Max

(*)  NOTE: I had one heck of a time getting the app to work -- when I went
to http://localhost:8080/index.jsp, I kept getting the standard index page
that you would see if you made the same request right after installing
Tomcat. After deploying the app every which way I could figure, I finally
realized that the index.jsp page of my app was older than the index.jsp page
from the ROOT application of my fresh Tomcat 4.1.18 install. I did the
securityfilter build before I installed Tomcat, so it didn't think it needed
to refresh the generated servlet class file. I touched my index.jsp file and
it started working after that. I later realized that I should have simply
deleted the $CATALINA_HOME/work/Standalone/localhost/_ directory to get rid
of any remnants of the old ROOT application. I know I'll remember that next
time, and I thought I'd share the tip in case it helps someone else.

(#) NOTE: The web.xml for this app has a welcome-page set to /index.jsp in
it. This seems to work fine if you deploy under a context path other than
the root, but it tries to redirect you to http://index.jsp when the app is
deployed in the root context. That seems wrong to me, but removing the
leading slash seemed to fix the behavior -- index.jsp instead of /index.jsp.
The Servlet spec gives index.html as an example, so perhaps it isn't
supposed to have the leading slash. I always thought it did some kind of
directory matching so you could specify different welcome-file elements for
different directories in the site, but I guess not. I just fixed that in the
CVS repository for securityfilter.


I'm trying to move my app that uses SecurityFilter to our production
 server and am suddenly running into some problems. It appears to be a
 logging issue but I cannot figure out how to fix it. It ran just fine
 on a dev machine, but now I'm moving it to a new box and making it the
 default context. Trying to deploy on Tomcat 4.1.8 with log4j-1.2.7
 installed in my WEB-APP/lib directory. The stack trace is:

 2003-03-20 09:56:09 StandardContext[]: Starting filters
 2003-03-20 09:56:09 StandardContext[]:  Starting filter 'Security Filter'
 2003-03-20 09:56:10 StandardContext[]: Exception starting filter Security
Filter
 java.lang.VerifyError: (class: org/apache/log4j/LogManager, method:
<clinit> signature:
()V) Incompatible argument to function
         at org.apache.log4j.Logger.getLogger(Logger.java:85)
         at
org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.java:1
53)
         at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.ja
va:288)
         at
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
         at org.apache.commons.digester.Digester.<init>(Digester.java:352)
         at
org.securityfilter.config.SecurityConfig.loadConfig(SecurityConfig.java:206)
         at
org.securityfilter.filter.SecurityFilter.init(SecurityFilter.java:220)
         at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilter
Config.java:254)
         at
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFil
terConfig.java:314)
         at
org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterCon
fig.java:120)
         at
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:31
58)
         at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3602)
         at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
         at
org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
         at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
         at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
         at
org.apache.catalina.core.StandardService.start(StandardService.java:497)
         at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2189)
         at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
         at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
         at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
         at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

 2003-03-20 09:56:10 StandardContext[]: Context startup failed due to
previous errors
 2003-03-20 09:56:10 StandardContext[]: Stopping

 I see a similar question was posted a couple of months ago, but I
 didn't see an answer.

 Thanks for any help!!

 cdh

 --
 Chris D. Halverson                         http://www.halverson.org/






-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en