I don't understand why would classloader-hack be necessary if I'm not putting log4j
lib into the global /lib directory. Check this out:
" servlet-hack reverses the normal class loader order. Instead of parent classloaders
having priority, child classloaders have priority."
Basically, it doesn't change anything in my case, because I don't have the .jar inside
my global lib anyway.
So here's the evergrowing stack I get when I don't put .jar into global lib, but put
it only into local (web-inf/lib):
[14:18:09,521][ad-pool-26]
_jsp._Error._Throwable__jsp._jspService(_Throwable__jsp.java:39): Throwable for IP
{127.0.0.1}
Requested URL: {http://localhost/Error/Throwable.jsp}
Referred by: {http://localhost//Account/Login.jsp}
java.lang.NoClassDefFoundError: org/apache/log4j/Category
at org.apache.taglibs.log.LoggerTag.getLoggingCategory(LoggerTag.java:124)
at org.apache.taglibs.log.LoggerTag.doAfterBody(LoggerTag.java:106)
at _jsp._Error._Throwable__jsp._jspService(_Throwable__jsp.java:56)
at com.caucho.jsp.JavaPage.service(JavaPage.java:75)
at com.caucho.jsp.Page.pageservice(Page.java:571)
at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:155)
at
com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:129)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:221)
at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:272)
at
com.caucho.server.webapp.RequestDispatcherImpl.error(RequestDispatcherImpl.java:119)
at com.caucho.jsp.PageContextImpl.handlePageException(PageContextImpl.java:972)
at _jsp._Account._LoginError__jsp._jspService(_LoginError__jsp.java:807)
at com.caucho.jsp.JavaPage.service(JavaPage.java:75)
at com.caucho.jsp.Page.pageservice(Page.java:571)
at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:155)
at
com.caucho.server.webapp.DispatchFilterChain.doFilter(DispatchFilterChain.java:129)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:221)
at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:272)
at
com.caucho.server.webapp.RequestDispatcherImpl.error(RequestDispatcherImpl.java:119)
at com.caucho.jsp.PageContextImpl.handlePageException(PageContextImpl.java:972)
at _jsp._Account._LoginHandler__jsp._jspService(_LoginHandler__jsp.java:119)
at com.caucho.jsp.JavaPage.service(JavaPage.java:75)
at com.caucho.jsp.Page.pageservice(Page.java:571)
at com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:155)
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:190)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:177)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:221)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:323)
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:430)
at com.caucho.util.ThreadPool.run(ThreadPool.java:377)
at java.lang.Thread.run(Thread.java:595)
BTW the "evergrowing" loop I mentioned earlier is actually my fault. My error page
logs the problem using log4j. But that causes a problem. Which forwards us to the
error page again. And the problem againâ and so on.
But I donât understand why wonât Resin find that class? The jar is in
WEB-INF/lib, all the other jars work there just fine. I successfully recreated that
problem on two computers already. I will also submit this to the resin user list, to
see their opinion on it.
> -----Original Message-----
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 27, 2004 1:36 PM
> To: Log4J Users List
> Subject: RE: log4j with with multiple web apps? URGENT!
>
>
> First, did you follow the other poster's instructions for configurting
> Resin to
> use the <webapp-classloader-hack> (or whatever it was called)? If not,
> that's
> an absolute necessity.
>
> Second, if you don't provide the stacktrace, there's not a lot we can do
> to
> help.
>
> BTW, what "one line" does it print out upon initialization? Is it
> printing this
> to standard out or to the file you configured to log to?
>
>
> Jake
>
> Quoting Ivan Jouikov <[EMAIL PROTECTED]>:
>
> > Ok I tried moving the .jar for log4j from global /lib into WEB-INF/lib
> >
> > Checked my permissions, everything's fine. Launched the server. First,
> it
> > prints out one line just fine (upon initialization). Then, after
> server is
> > started up, I try to log something, and I get this huge recursive stack,
> > which leads to one message:
> >
> > "NoClassDefFound: org/apache/log4j/Category"
> >
> > I double checked my permissions, I even checked the .jar file inside my
> > /web-inf/lib, everything seems to be just fine.
> >
> > So how is it that 1 line gets printed, but everything else gives me
> bullcrap?
> >
> > (BTW right after that application is loaded, the second application
> loads,
> > which also has log4j's .jar inside its WEB-INF/lib, and it also
> configures
> > its own loggers. I haven't checked erros on that one yet, but just
> thought
> > I'd mention it.)
> >
> > > -----Original Message-----
> > > From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, September 26, 2004 10:12 AM
> > > To: Log4J Users List
> > > Subject: Re: log4j with with multiple web apps? URGENT!
> > >
> > > Where do you have log4j.jar? Is it in each application's WEB-INF/lib
> > > directory or some shared directory? The quick fix (assuming Resin
> > > enforces
> > > servlet spec recommended classloading behavior) is to do the former.
> The
> > > more involved fix is to use a logger repository selector. One exists
> for
> > > Log4j-1.2.x in the log4j-sandbox project. It is based on JNDI. See
> > > here...
> > > http://wiki.apache.org/logging-log4j/AppContainerLogging
> > >
> > > If you decide to use the logger repository selector approach, make
> sure to
> > > check out the LOG4J_SANDBOX_ALPHA3 tag because the
> ContextJNDISelector,
> > > which is the repository selector you would use, doesn't exist in the
> > > HEAD. It was removed because Log4j-1.3 CVS now contains that code,
> only
> > > modified significantly to work with Log4j-1.3's new API and features.
> > > Read
> > > the Javadoc of the InitContextListener and the ContextJNDISelector to
> > > understand how to use this stuff. Short term, I really recommend
> putting
> > > log4j.jar in WEB-INF/lib because that is going to be much more simple
> to
> > > get up and running quickly.
> > >
> > > Jake
> > >
> > > At 07:31 PM 9/25/2004 -0700, you wrote:
> > >
> > > >Hi everyone!
> > > >
> > > >I am running resin-3.0.7 and I am using latest log4j version.
> Everything
> > > >was fine running log4j when I had only 1 application on my server -
> > > >siblumber.com. Log4j was setup up like this - /WEB-INF/log4j.xml
> which
> > > >uses ${user.dir}/WEB-INF/logs/logname.txt in all its appenders.
> > > >
> > > >Everthing was fine up until I deployed a new application -
> > > >royaleskincare.com. It uses the EXACT same approach as siblumber.com,
> and
> > > >here's what happens:
> > > >
> > > >1. Server is started up
> > > >2. application royaleskicare.com is started up
> > > >3. its event listener configures log4j using DOMConfigurator
> > > >4. it writes a single line into royaleskincare.com/.../trace.txt
> > > >(everything's fine so far)
> > > >5. application siblumber.com is started up
> > > >6. its event listener configures log4j using DOMConfigurator
> > > >7. it writes a single line into siblumber.com/.../trace.txt
> > > >
> > > >After the server is finished starting up, I check all my loggers, and
> it
> > > >turns out that BOTH royaleskincare.com AND siblumber.com loggers
> point to
> > > >"siblumber.com/.../logs/logname.txt"
> > > >
> > > >It seems that when the second application starts up, it re-configures
> > > >log4j for the first application. But how is it possible? Aren't web
> apps
> > > >ran in separate JVMs? Even if I check System.getProperty("user.dir"),
> > > they
> > > >point to their approporiate directories.
> > > >
> > > >So does log4j uses some kind of JVM-independent external
> configuration
> > > >file that causes it to mess up my first application?
> > > >
> > > >Any help is appreciated, thanks in advance!
> > > >
> > > >
> > > >
> > > >----------
> > > >Best Regards,
> > > >
> > > >Ivan V. Jouikov
> > > >(206) 228-6670
> > > >
> > > ><http://ablogic.net>215989.jpg
> > > >
> > > >
> > > >
> > > >---
> > > >Outgoing mail is certified Virus Free.
> > > >Checked by AVG anti-virus system (http://www.grisoft.com).
> > > >Version: 6.0.766 / Virus Database: 513 - Release Date: 17.09.2004
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.766 / Virus Database: 513 - Release Date: 17.09.2004
> > >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.766 / Virus Database: 513 - Release Date: 17.09.2004
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.766 / Virus Database: 513 - Release Date: 17.09.2004
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17.09.2004
