Hi Craig,
I agree with you - bundling the javax.naming... is a bit of a problem waiting to
happen.
The original reason was as a 'convenience' for end-users that weren't on JDK 1.3,
as it was the
same classes from JSEE 1.2.1 there wasn't a conflict.
Of course who knows what the future will bring ;-)
I haven't changed StandardContext - though I have munged ContextConfig though -
could this be part of the
problem? ContextConfig now will refer to some classes that are based on 'my stuff'
which do, ultimately
call some javax.naming.
I still can't explain that odd error -what argument and what function?
-Thom
"Craig R. McClanahan" wrote:
> 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
> >
> >
> >
--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html
