You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "T. Park" <tp...@borland.com> on 2001/03/30 01:56:01 UTC
More naming woes...
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?
-Thom
Exception follows:
C:\WebServers\jakarta-tomcat-4.0\bin>catalina run -nonaming
Using CLASSPATH:
..\bin\bootstrap.jar;c:\DevTools\JavaTools\JBuilder4\jdk1.3\lib
\tools.jar
Exception during startup processing
java.lang.reflect.InvocationTargetException:
java.lang.NoClassDefFoundError: org
/apache/naming/TransactionRef
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)
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)
--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html
Re: More naming woes...
Posted by "T. Park" <tp...@borland.com>.
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
Re: More naming woes...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
>
>
>
Re: More naming woes...
Posted by "T. Park" <tp...@borland.com>.
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.
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
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)
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)
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
Re: More naming woes...
Posted by Remy Maucherat <re...@apache.org>.
> 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