You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mikolaj Rydzewski <mi...@ceti.pl> on 2009/03/18 15:47:05 UTC
JNDI: Name java:comp is not bound in this Context
Hello everybody,
I have faced interesting issue recently. Here are details:
I had to implement custom log4j appender that logs particular messages
to database (JDBCAppender was not enough). So I did, using JNDI based
datasources, not a difficult task. Of course I updated server.xml,
context.xml and web.xml with datasource definition, etc.
Unfortunately every time I deployed application there was "Name
java:comp is not bound in this Context" error in logfile (see
stacktrace at end of email).
It's strange, isn't it? "java:comp" is a standard Java root for all JNDI
based resources. So I don't understand how does it happen that it is not
bound.
My appender implementation tries to lookup datasource in JNDI just after
all properties has been set (recommended way -
http://tinyurl.com/dg4fxa). Then I moved JNDI lookup code to method that
actully performs logging. And it started to work!
So, to summarize. My custom log4j code was not able to lookup JNDI
resources during deployment process. But it was able to during normal
webapplication usage.
Is it expected behaviour? It looks like Tomcat (5.5.26 on Sun's JDK 1.5
in my case) fills JNDI context information after webapplication deployment.
On other hand, I wonder how does it keep separate copies of JNDI catalog
per webapplication.
javax.naming.NameNotFoundException: Name java:comp is not bound in this
Context
at org.apache.naming.NamingContext.lookup(NamingContext.java:770)
at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
mypackage.DataSourceAppender.activateOptions(DataSourceAppender.java:34)
at
org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:256)
at
org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:220)
at
org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)
at
org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:163)
at
org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:425)
at
org.apache.log4j.xml.DOMConfigurator.parseCategory(DOMConfigurator.java:345)
at
org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:827)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
at
org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:122)
at org.apache.log4j.Logger.getLogger(Logger.java:104)
at
org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:289)
at
org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:109)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1116)
at
org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:914)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704)
at
org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4119)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
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:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
--
Mikolaj Rydzewski <mi...@ceti.pl>
Re: JNDI: Name java:comp is not bound in this Context
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Christopher Schultz wrote:
> Since you have written your own appender, maybe you could change it to
> fail gracefully (say, log messages to the console) when the JNDI
> DataSource is not available, retain a copy of a certain number of log
> messages (say, 100), and then write them all to the DataSource once it
> becomes available.
>
Well, I know root of the problem now. So workaround implementation is
not a problem.
--
Mikolaj Rydzewski <mi...@ceti.pl>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mikolaj,
On 3/19/2009 11:04 AM, Mikolaj Rydzewski wrote:
> Caldarale, Charles R wrote:
>> That may be true, but there's no guarantee that your classes will be
>> loaded in any specific order, nor that resources will be registered
>> prior to classloading; the spec only indicates the resources will be
>> available prior to any calls to the initialization methods of
>> listeners and servlets.
>>
> Thank you, that explains everything.
Since you have written your own appender, maybe you could change it to
fail gracefully (say, log messages to the console) when the JNDI
DataSource is not available, retain a copy of a certain number of log
messages (say, 100), and then write them all to the DataSource once it
becomes available.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknCZ7QACgkQ9CaO5/Lv0PAUNQCeJ6f2yNukMIVOeQ5VhjUTvS3K
s6cAnRHu4ikdqUYrhoPS3LqwIatIH5Un
=AcCN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Caldarale, Charles R wrote:
> That may be true, but there's no guarantee that your classes will be loaded in any specific order, nor that resources will be registered prior to classloading; the spec only indicates the resources will be available prior to any calls to the initialization methods of listeners and servlets.
>
Thank you, that explains everything.
--
Mikolaj Rydzewski <mi...@ceti.pl>
RE: JNDI: Name java:comp is not bound in this Context
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mikolaj Rydzewski [mailto:miki@ceti.pl]
> Subject: Re: JNDI: Name java:comp is not bound in this Context
>
> If I'm not wrong, log4j initialization should take place during
> initialization of static 'log' field.
That may be true, but there's no guarantee that your classes will be loaded in any specific order, nor that resources will be registered prior to classloading; the spec only indicates the resources will be available prior to any calls to the initialization methods of listeners and servlets.
>From your stack trace, you can see that the logger is being set up very early in the game:
org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:289)
org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:109)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1116)
org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:914)
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704)
org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381)
org.apache.catalina.core.StandardContext.start(StandardContext.java:4119)
This is well before the resources are established, and of course before any of your listeners or servlets are initialized.
You can look at the start() method of org/apache/catalina/core/StandardContext.java for details about the initialization sequence.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
Caldarale, Charles R wrote:
>> From: Mikolaj Rydzewski [mailto:miki@ceti.pl]
>> Subject: Re: JNDI: Name java:comp is not bound in this Context
>>
>> So I rather think, that Tomcat fills JNDI information
>> after webapp deployment.
>>
>
> Not really after, just during. I'm still looking through the code, but the logger for the webapp is initialized very early in the process, which makes sense.
>
>
>> But anyway, why does log4j initialization takes place
>> before JNDI context is ready?
>>
>
> The JNDI context is specific to the webapp; if errors occur during its population, having the webapp's logger around to record them would be beneficial. One or the other has to come first, and the spec gives no guidance with respect to loggers, so it appears Tomcat chose to initialize the webapp's logger first. Seems quite reasonable to me.
>
Thanks Chuck for your input.
Do Tomcat has to do anything with logger initialization? As you can see
in stacktrace, I use commons-logging, log4j and common idiom:
private final static Log log = LogFactory.getLog(MyClass.class);
If I'm not wrong, log4j initialization should take place during
initialization of static 'log' field. And that happens when JVM loads
specific (my) class. And that can happen, for the first time, during
context listeners loading. So it should happen after JNDI context
population. Am I right?
I'm not arguing with you, just trying to understand the cause of my
problem ;-)
--
Mikolaj Rydzewski <mi...@ceti.pl>
RE: JNDI: Name java:comp is not bound in this Context
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mikolaj Rydzewski [mailto:miki@ceti.pl]
> Subject: Re: JNDI: Name java:comp is not bound in this Context
>
> So I rather think, that Tomcat fills JNDI information
> after webapp deployment.
Not really after, just during. I'm still looking through the code, but the logger for the webapp is initialized very early in the process, which makes sense.
> But anyway, why does log4j initialization takes place
> before JNDI context is ready?
The JNDI context is specific to the webapp; if errors occur during its population, having the webapp's logger around to record them would be beneficial. One or the other has to come first, and the spec gives no guidance with respect to loggers, so it appears Tomcat chose to initialize the webapp's logger first. Seems quite reasonable to me.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
David Smith wrote:
> Try java:/comp instead. If that doesn't help, then we'll need more info:
>
> - OS:
> - where you got tomcat from (tomcat.apache.org or third party repackage)
> - Details of your setup like what's in tomcat's common/lib folder?
> - Config (relevant parts of server.xml, the webapp's context.xml and
> WEB-INF/web.xml)
> - The code used to access JNDI if available:
>
Hi David,
What does help is to perform JNDI lookup not during deployment, but with
first logging attempt.
So I rather think, that Tomcat (I know, I use old version, but I have
to) fills JNDI information after webapp deployment. Can anybody confirm
that? But anyway, why does log4j initialization takes place before JNDI
context is ready?
My setup is quite complicated, there're several webapps, Josso SSO (it
requires its jars to be present in tomcat's common/lib), etc. It happens
on Ubuntu Linux, Tomcat extracted from tarball from tomcat.apache.org.
My JNDI lookup code is correct (because it works, but not during
deployment). Anyway, here's appender code:
public class DataSourceAppender extends AsyncAppender {
private DataSource dataSource;
private String jndi;
public String getJndi() {
return jndi;
}
public void setJndi(String jndi) {
this.jndi = jndi;
}
@Override
public void append(LoggingEvent event) {
String statement = getLayout().format(event);
Connection c = getConnection();
// perform logging, etc
}
@Override
public void activateOptions() {
super.activateOptions();
// don't know why, but I cannot perform lookup here. JNDI
context is not available yet
// lookupDataSource();
}
@Override
protected Connection getConnection() {
Connection c = null;
try {
if (dataSource == null) {
lookupDataSource();
}
if (dataSource != null) {
c = dataSource.getConnection();
}
}
catch (Exception e) {
System.err.println("Cannot retrieve connection from
datasource");
e.printStackTrace(System.err);
}
return c;
}
private synchronized void lookupDataSource() {
if (dataSource == null) {
try {
InitialContext ctx = new InitialContext();
dataSource = (DataSource) ctx.lookup(jndi);
}
catch (Exception e) {
System.err.println("Cannot retrieve DataSource from JNDI
" + jndi);
e.printStackTrace(System.err);
}
}
}
}
And this is the way I configure this appender:
<appender name="JDBC" class="mypackage.DataSourceAppender">
<param name="jndi" value="java:comp/env/jdbc/sir"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="insert into error_log ...."/>
</layout>
<filter class="org.apache.log4j.varia.LevelRangeFilter">
<param name="LevelMin" value="INFO" />
</filter>
</appender>
--
Mikolaj Rydzewski <mi...@ceti.pl>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by David Smith <dn...@cornell.edu>.
Caldarale, Charles R wrote:
>> From: David Smith [mailto:dns4@cornell.edu]
>> Subject: Re: JNDI: Name java:comp is not bound in this Context
>>
>> My copy of the spec is at work at the moment
>>
>
> What? You use paper?
>
>
:-) I printed just one a few years ago while testing a new copier the
department I worked for was evaluating. The printer was one of those
big ones that double sides, hole punches and ... well ... virtually
everything except read it to you. I still have it and still use it (the
spec that is), so it's not waste just yet.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JNDI: Name java:comp is not bound in this Context
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Smith [mailto:dns4@cornell.edu]
> Subject: Re: JNDI: Name java:comp is not bound in this Context
>
> My copy of the spec is at work at the moment
What? You use paper?
> Someone should probably fix the docs at
> http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> since it recommends exactly what I posted.
It's the same way in the 6.0 docs. For all I know, a leading slash might be ignored, but I agree the docs should be fixed to be consistent with the spec.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JNDI: Name java:comp is not bound in this Context
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Caldarale, Charles R
> Subject: RE: JNDI: Name java:comp is not bound in this Context
>
> For all I know, a leading slash might be ignored
It looks like "java:comp/env" and "java:/comp/env" are equivalent; the leading slash is indeed ignored, and the same object is retrieved for either name. Don't know if that holds true for all containers, or just Tomcat.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by David Smith <dn...@cornell.edu>.
Caldarale, Charles R wrote:
>> From: David Smith [mailto:dns4@cornell.edu]
>> Subject: Re: JNDI: Name java:comp is not bound in this Context
>>
>> Try java:/comp instead.
>>
>
> That's not in the spec; what is in the spec is java:comp/env, so java:comp should work.
>
> - Chuck
>
>
>
My copy of the spec is at work at the moment, so I used the nearest
reference I could think of .. the tomcat docs. Someone should probably
fix the docs at
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
since it recommends exactly what I posted. In particular, the Oracle
section's code example.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: JNDI: Name java:comp is not bound in this Context
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: David Smith [mailto:dns4@cornell.edu]
> Subject: Re: JNDI: Name java:comp is not bound in this Context
>
> Try java:/comp instead.
That's not in the spec; what is in the spec is java:comp/env, so java:comp should work.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JNDI: Name java:comp is not bound in this Context
Posted by David Smith <dn...@cornell.edu>.
Try java:/comp instead. If that doesn't help, then we'll need more info:
- OS:
- where you got tomcat from (tomcat.apache.org or third party repackage)
- Details of your setup like what's in tomcat's common/lib folder?
- Config (relevant parts of server.xml, the webapp's context.xml and
WEB-INF/web.xml)
- The code used to access JNDI if available:
Links to any docs you used to get you to this point would also be great
just in case they are providing bad advice.
--David
Mikolaj Rydzewski wrote:
> Hello everybody,
>
> I have faced interesting issue recently. Here are details:
> I had to implement custom log4j appender that logs particular messages
> to database (JDBCAppender was not enough). So I did, using JNDI based
> datasources, not a difficult task. Of course I updated server.xml,
> context.xml and web.xml with datasource definition, etc.
>
> Unfortunately every time I deployed application there was "Name
> java:comp is not bound in this Context" error in logfile (see
> stacktrace at end of email).
> It's strange, isn't it? "java:comp" is a standard Java root for all
> JNDI based resources. So I don't understand how does it happen that it
> is not bound.
>
> My appender implementation tries to lookup datasource in JNDI just
> after all properties has been set (recommended way -
> http://tinyurl.com/dg4fxa). Then I moved JNDI lookup code to method
> that actully performs logging. And it started to work!
>
> So, to summarize. My custom log4j code was not able to lookup JNDI
> resources during deployment process. But it was able to during normal
> webapplication usage.
>
> Is it expected behaviour? It looks like Tomcat (5.5.26 on Sun's JDK
> 1.5 in my case) fills JNDI context information after webapplication
> deployment.
>
> On other hand, I wonder how does it keep separate copies of JNDI
> catalog per webapplication.
>
>
> javax.naming.NameNotFoundException: Name java:comp is not bound in
> this Context
> at org.apache.naming.NamingContext.lookup(NamingContext.java:770)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at
> mypackage.DataSourceAppender.activateOptions(DataSourceAppender.java:34)
> at
> org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:256)
> at
> org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:220)
>
> at
> org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)
>
> at
> org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:163)
>
> at
> org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:425)
>
> at
> org.apache.log4j.xml.DOMConfigurator.parseCategory(DOMConfigurator.java:345)
>
> at
> org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:827)
> at
> org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
>
> at
> org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
>
> at
> org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
>
> at org.apache.log4j.LogManager.<clinit>(LogManager.java:122)
> at org.apache.log4j.Logger.getLogger(Logger.java:104)
> at
> org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:289)
>
> at
> org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:109)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1116)
>
> at
> org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:914)
>
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:604)
>
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:336)
>
> at
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704)
> at
> org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381)
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4119)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
>
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
>
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
>
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
>
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:448)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
> 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:585)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
>
>
>
>
--
David Smith
Programmer/Analyst
College of Agriculture and Life Sciences
Cornell University
B32 Morrison Hall
Ithaca, NY 14853
Phone: (607) 255-4334
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org