On Thu, 29 Mar 2001, T. Park wrote:
> Remy,
>
> thanks, that's good to hear - I'm still having a nightmare of a time resolving
> one last issue.
>
> I have a large jar file that contains, amongst other things (e.g. an ejb
> container, a namingservice etc) javax.naming package.
>
Are you including the javax.naming.* API classes (from JNDI) yourself? If
so, this seems like a bad idea because they will already be in the JDK's
core classes (on a JDK 1.3 platform) or added to Tomcat's common
classloader (on a JDK 1.2 platform). Doing this sounds like asking for
conflicts.
> If I deploy this to the common/lib and start tomcat I get the following
> exception however,
> if I remove the javax.naming package from my jarfile the issue goes
away (but
> burns me in a different situation
> later):
>
> I'm hoping that when the naming references are placed in a jar file separate
> from StandardContext, this very strange problem
> may clear up - out of interest - any one have any idea what the error means?
> (After all - the method createNamingContext isn't actually
> being called (or at least it shouldn't be!)
>
> -Thom
>
> Here's the exception:
>
> Exception during startup processing
> java.lang.reflect.InvocationTargetException: java.lang.VerifyError: (class:
> org/
> apache/catalina/core/StandardContext, method: createNamingContext signature:
> ()V
> ) Incompatible argument to function
Normally, this kind of error would mean you've compiled against one
version of the createNamingContext() method signature, and then
StandardContext was changed but the calling code was not recompiled. Hmm,
that seems hard to do when createNamingContext() is a private method ...
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:120)
> at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
> at
> org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)
>
> at
> org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91
> )
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
> at com.sun.xml.parser.Parser.parse(Parser.java:284)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:126)
> at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:657)
This is where the server.xml file is being read. The next challenge is to
figure out what line number being processed when the error occurs. You
can get more copious output by adding "-debug" to the startup command
line.
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:627)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177)
>
Craig
> Remy Maucherat wrote:
>
> > > Hi Folks,
> > >
> > > I'm [still] trying to get an alternative naming service plugged into
> > > Tomcat 4.
> > >
> > > I managed to hack together a working environment but, unfortunately, it
> > > wouldn't cut it long-term.
> > >
> > > I've discovered that if I run with naming disabled (catalina run
> > > -nonaming) it seems
> > > that tomcat still goes looking for apache naming stuff.
> > >
> > > I discovered this when I moved the naming.jar out of common/lib and got
> > > the following exception which suggests to me
> > > that naming isn't going to be replaced willingly ;-)
> > >
> > > Any suggestions how I go about plugging in an alternative naming
> > > service?
> >
> > The dir contexts are *also* part of naming.jar, so naming.jar has to be
> > there if you want Catalina to run.
> >
> > Although Standard context has actual dependencies on
> > org.apache.naming.xxxRef objects and others, I promise that if you're using
> > "-nonaming" none of these will actually get initialized or used. I can sign
> > a paper if you want ;)
> > It's safe to say that we'll move the naming initialization to a separate
> > class (but that will happen after b2).
> >
> > Remy
>
> --
> http://www.borland.com/newsgroups
> http://www.borland.com/devsupport/disclaim.html
>
>
>
