mod_webapp help!
Hi Folks,
Can anyone advise me how to build it using the sources supplied with
tomcat 4.0 b3?
My end goal is to be able to build it on NT with MSVC 6.0, but I've been
trying to get it to
compile on Solaris 2.8 with the 6.1 C compiler.
I know that it was written for gcc - my next step is to try to use gcc -
I was hoping to avoid having to employ gcc as it's use will cause me
some 'productization' headaches)
I'm trying to findout what WA_LOG should be - it's referred to in
several places but there is not definition of it in the makefiles or the
C code.
Also, some of the code constructs appear to be C++ rather than C - was
this intentional?
e.g.
struct wa_connection {}
where wa_connection is subsequently used as a datatype.
In 'strict' C it would be more proper to write something like:
typedef struct wa_connection wa_connection_t;
struct wa_connection {...}
and use wa_connection_t as the datatype.
If I feed the former to a 'strict' C compiler - it's not a happy camper.
Note: I'm not trying to be picky here - this just came to light when I
tried to use Microsoft C and Solaris C on the sources,
as there were no binaries available for the platforms that I'm using.
I guess my next step is to try with gcc on Solaris and then on windows
- with some porting work ;-)
Again - is there anyone doing the Win NT work at the moment? If not I'm
more than happy to volunteer.
-Thom
--
http://www.borland.com/newsgroups
http://www.borland.com/devsupport/disclaim.html
mod_webapp source?
Hi Folks, I've been playing with porting the mod_webapp over to Windows NT and am having a heck of a time with undefined symbols. For instance where is WA_LOG defined? Are the sources supplied (in webapplib) complete? I'd appreciate any guidance (especially if someone else has already done/is already doing) a port. thanks, Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: More naming woes...
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* pa
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\bincatalina 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...
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: Cause found [was Re: How do I use a non-apache naming servicewith tomcat 4?]
Craig,Remy, downloading the latest nightly build resolved my problem... thanks! ...but only after I dropped that 'big everything' jar into the common/lib folder. So there seems to be a chicken egg thing regarding what order certain components need to be in for the new tomcat to play with an alternative naming service. My InstanceListener class goes into server/lib just fine, but the support class (I.e. the one containing javax.naming) needs to go in the common area. Can you tell me why this would be? I know it's something to do with the new classloading scheme but I can't see why it would matter. -Thom "Craig R. McClanahan" wrote: On Mon, 26 Mar 2001, T. Park wrote: Hi Remy, I'm running tomcat 4 beta 1. I'll download tonight's latest build and see how I fare with that. Thanks so much for the support! -Thom p.s. is there a b2 drop in the near future - I'm trying to focus my integration efforts on the nearest milestone build. There will be soon, but I've been notified that someone is working on a "real" patch for the sealing violation problems under JDK 1.3 JVMs. I'd like to give him a chance to finish before cutting beta 2. Since I'm going to be at O'Reilly Java Conference for the remainder of this week (I'm speaking at 4:15 on Thursday about Web Application Architectures), the earliest possible time for a beta 2 release will be this weekend. In the mean time, working with a recent nightly build will save you the time it takes to deal with issues that have already been fixed (and there have been around 200 CVS commits on Tomcat 4.0 since beta 1). Craig -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
How do I use a non-apache naming service with tomcat 4?
Hello, I'm attempting to use an alternative naming service with tomcat 4.x and running into some difficulties. This may be a result of my lack of understanding on how to go about this but please read on... I start tomcat 4 with both -nonaming and -Dcatalina.useNaming=false added as parameters to the catalina run batch procedure. I have added my own naming jar files to the system class path. When tomcat starts up it fails in StandardContext with the reflection error complaining about the signature of the method call "createNamingContext" (Follows later). If I remove the jar file containing my naming support all works are normal. e.g.:: 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 org.xml.sax.helpers.XMLReaderAdapter.startElement(XMLReaderAdapter.ja va:329) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1444) at org.apache.crimson.parser.Parser2.content(Parser2.java:1695) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461) at org.apache.crimson.parser.Parser2.content(Parser2.java:1695) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461) at org.apache.crimson.parser.Parser2.content(Parser2.java:1695) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461) at org.apache.crimson.parser.Parser2.content(Parser2.java:1695) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1461) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:499) at org.apache.crimson.parser.Parser2.parse(Parser2.java:304) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:433) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:300) at javax.xml.parsers.SAXParser.parse(SAXParser.java:245) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228) at org.apache.catalina.startup.Catalina.start(Catalina.java:625) at org.apache.catalina.startup.Catalina.execute(Catalina.java:595) at org.apache.catalina.startup.Catalina.process(Catalina.java:176) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:157) I would have thought with naming disabled then the routine wouldn't be called, however, I noticed a further scary thing - there are references throughout StandardContext.java that refer to the org.apache.naming service provider - Is this part of the problem? Could it be that somehow the JVM is finding references to the 'native' naming servive that conflict with the one I'm trying to use and I'm getting burned. If so how do I 'plug in' an alternative naming service to org.apache.naming with tomcat 4? -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: How do I use a non-apache naming service with tomcat 4?
More info. I pulled the routines I needed out of my 'big everything' jar file and I can now get my jndi stuff to work with tomcat4. The problemi is that I still need to get the other stuff in that jar file to play nice with tomcat. but, for now, the problem looks to be in my camp. Thanks for the support/encouragement. -Thom p.s. Odd error all the same don't you think? -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Cause found [was Re: How do I use a non-apache naming service with tomcat 4?]
Guys, I've isolated the cause of the problem down to the inclusion of the javax.naming package in my 'big everything' jar. If I remove the javax.naming package from the jar file, then all works well, if not, we get that wierd 'signature' problem with createNamingContext. (with or without enabling naming). Would it seem reasonable not to load naming support jars if tomcat isn't going to be running a [native] naming service? My problem here is I have a naming service I want to use and is packaged with the corresponding javax.naming package that it is based on the problem is that I'm unable (by default) to control what jndi stuff get's stuffed on the classpath of tomcat I'm unable to swap these (the naming support jars) around as tomcat's stuff seems to have been compiled against a different rev of the javax.naming stuff. So - Do you know what version of javax.naming is in tomcat 4's jndi.jar? I'm bundling the rev that came with j2ee 1.2.1 -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: Cause found [was Re: How do I use a non-apache naming service with tomcat 4?]
Hi Remy, I'm running tomcat 4 beta 1. I'll download tonight's latest build and see how I fare with that. Thanks so much for the support! -Thom p.s. is there a b2 drop in the near future - I'm trying to focus my integration efforts on the nearest milestone build. Remy Maucherat wrote: Guys, I've isolated the cause of the problem down to the inclusion of the javax.naming package in my 'big everything' jar. If I remove the javax.naming package from the jar file, then all works well, if not, we get that wierd 'signature' problem with createNamingContext. (with or without enabling naming). Would it seem reasonable not to load naming support jars if tomcat isn't going to be running a [native] naming service? Which version of TC 4 are you using ? I believe the latest nightly builds could fix those problems. My problem here is I have a naming service I want to use and is packaged with the corresponding javax.naming package that it is based on the problem is that I'm unable (by default) to control what jndi stuff get's stuffed on the classpath of tomcat I'm unable to swap these (the naming support jars) around as tomcat's stuff seems to have been compiled against a different rev of the javax.naming stuff. So - Do you know what version of javax.naming is in tomcat 4's jndi.jar? It's the same as yours, but loaded by a different classloader, so it's not compatible anyway. Remy -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Catalina vs. preServletInit et. al.
Hello, I'm a newbie to the Catalina code line and need some guidance (lots actually)... I have a custom interceptor that works really well with Tomcat 3.x that does some special setup work in the preServletInit/postServletInit, preService/postService and preServletDestroy/postServletDestroy methods of the special RequestInterceptor. My problem is determining functional equivalents to these in Catalina. Can anyone give me any pointers - I sort of lost my way in the source code and documentation (primarily due to existing references to 'interceptors' in both comments and docs.) Is there still a way to do some pre/post processing for each corresponding servlet call (init,destroy and service). I looked at VavleBase and couldn't see any direct comparison. -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Catalina vs.preServletInit et. al.
Hello, I'm a newbie to the Catalina code line and need some guidance (lots actually)... I have a custom interceptor that works really well with Tomcat 3.x that does some special setup work in the preServletInit/postServletInit, preService/postService and preServletDestroy/postServletDestroy methods of the special RequestInterceptor. My problem is determining functional equivalents to these in Catalina. Can anyone give me any pointers - I sort of lost my way in the source code and documentation (primarily due to existing references to 'interceptors' in both comments and docs.) Is there still a way to do some pre/post processing for each corresponding servlet call (init,destroy and service). I looked at VavleBase and couldn't see any direct comparison. -Thom
