Re: jk2 problems with libapr.so
On Mon, Jan 14, 2002 at 05:12:29PM +0100, jean-frederic clere wrote: Hi, I am playing with jk2 and I have noted that the loadNative() in AprImpl fails: +++ java.lang.UnsatisfiedLinkError: /home/jakarta/jakarta-tomcat-4.0.1/webapps/jk/WEB-INF/jk2/jni/libapr.so: /home/jakarta/jakarta-tomcat-4.0.1/webapps/jk/WEB-INF/jk2/jni/libapr.so: undefined symbol: crypt at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1277) at java.lang.Runtime.load0(Runtime.java:698) at java.lang.System.load(System.java:797) at org.apache.jk.apr.AprImpl.loadNative(AprImpl.java:90) at org.apache.jk.apr.AprImpl.loadNative(AprImpl.java:78) at org.apache.jk.common.ChannelUn.init(ChannelUn.java:135) +++ The problem is that apr needs other dynamic library. How should we solve the problem?: 1 - Loading the missing libraries in the JVM (via System.load()) The list of needed library is in APRVARS. 2 - Link jni_connect.so against a static libapr.a (like in mod_webapp for Apache-1.3). something like: gcc -shared -lm -lcrypt -lnsl -ldl -o jni_connect.so ... libapr.a Any comments? Sorry for replying to this so late. As an FYI, APRVARS will soon be removed from APR. Take a look at the replacement apr-config and apu-config (in apr and apr-util respectively). It's not yet complete (that's why APRVARS hasn't been removed yet), but if you see something missing let us know. -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_webapp Solaris 8
On Wed, Nov 28, 2001 at 10:08:28AM -0800, Justin Erenkrantz wrote: On Wed, Nov 28, 2001 at 12:31:13PM -0500, mgoyer wrote: Httpd was built with gcc-3.0.1 the same version that I'm using for mod_webapp. Then, just add -R/path/to/gcc-3.0.1/lib to your LDFLAGS for httpd. There's a trick for getting the path, try `gcc -print-libgcc-file-name`. Barring syntax errors, you could probably do something like LIBS=`gcc -print-libgcc-file-name`. I don't suggest dynamically linking against libgcc. Another solution is to use the GNU linker (gld from binutils). gld knows about libgcc and implicitly pulls symbols from it when needed. BTW, if you upgrade to libtool-1.4.2 you'll get a nice little warning about using the solaris linker with gcc. -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mod_webapp Solaris 8
On Wed, Nov 28, 2001 at 03:30:38PM -0500, Matt Goyer wrote: I've got both binutils and libtool installed. How do I get it to use the GNU linker instead? Though 'ld -v' tells me ld -v 'GNU ld version 2.11.2 (with BFD 2.11.2)' That's a good question. I'm not seeing any relevant flags or params that one can pass to gcc, and I am seing the string '/usr/ccs/bin/ld' showing up in the gcc binary, so I'm guessing it has to be configured at compile-time. Did you try setting the LD environment variable? The only surefire ways I know of making this work are: - add libgcc.a to your linker line (ie the output of `gcc -print-libgcc-file-name`) - recompile gcc to use the gnu linker -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem compiling mod_webapp for IBM HTTP Server 1.9.19 running on AIX 4.3.3. Please help save Tomcat for a high profile project in Switzerland
Lurking indeed... ;) On Sun, Nov 18, 2001 at 10:34:42AM -0800, Justin Erenkrantz wrote: On Sat, Nov 17, 2001 at 08:51:24PM +0100, [EMAIL PROTECTED] wrote: First of all I attempt to calmly summarize the problem and only then let my emotions get through. You're certainly not the first to be frustrated by this problem. :) My insufficient knowledge of AIX platforms prevents me from successfully compiling mod_webapp (as well mod_jk) on AIX 4.3.3 platform. Tomcat itself appears to be running flawlessly. Unfortunately due to my meager knowledge of AIX I seem to be unable to recompile neither mod_webapp nor mod_jk for the specified platform. Actually compilation worked fine in both cases. What did fail was the ld linker. As far as I can judge about possible cause of failure, the linker requires a module export (.exp) file in order to be able successfully complete linking process. In this respect AIX appears to differ from Unixes, as I had no problems at all building mod_webapp mod_jk under Linux (Mandrake 8.0 Mandrake 8.1) as well as Solaris 8. The problem is aggravated by the managements desire to use IBM HTTP Server instead of plain Apache mainly due to IBMs SSL support, which is perceived to be more trustworthy and secure. Is my assumption right? If yes, is there a way I could generate that damn .exp file for mod_webapp? I could also live with mod_jk as a fallback scenario. [snip] I know that Aaron Bannert spent some time working with the IBM httpd folks (Victor, Greg, Bill, Jeff, etc.) trying to get AIX DSO support for Apache 2.0 and APR. I believe the eventual conclusion from the IBM AIX gurus in Austin was that the linker is not capable of handling external dependencies in an acceptable manner. Their recommendation was to wait for the next major release of AIX which would have a new linker. But, this isn't very helpful to you or to us httpd folks though. As of yet we have not been able to tame the beast that is the AIX linker WRT apache-2.0 and DSOs. The essential problem has to do with the mechanism used at runtime to load and dynamically link modules, and the aparent inability of the AIX linker to deal with interdependent shared objects. In the short term this really only applies to apache-2.0 and modules that automatically depend on other libraries, like how mod_webapp depends on libapr and libaprutil. The problem in this scenario is that libaprutil actually depends on symbols exported from libapr. First-order runtime linkages seem to work fine, but as soon as you hit a symbol that depends on that second library (even if they are statically linked into the same shared object) you'll get a segfault. It's entirely possible that over in httpd-2.0 we're doing something wrong, but given the number of people looking at this issue, that is becomming less and less likely. I have been informed by the management that if problem is not resolved by mid next week Tomcat will be replaced with WebSphere 3.5 Standard Edition. My first impression to this post was to suggest you contact your vendor for a solution. (My second and more emotionally based response was to suggest you change operating systems. ;) Hope that provides some insight, -aaron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: Apache/Tomcat Collaboration
On Mon, Oct 01, 2001 at 12:10:36PM -0700, [EMAIL PROTECTED] wrote: On Mon, 1 Oct 2001, Aaron Bannert wrote: What are the main advantages to using an in-process VM as opposed to an out-of-process VM bridged over some form of IPC (like mod_webapp/mod_jk/mod_jserv)? Well, using in-process VM ( like mod_jk ) has many more benefits than just reduced request/response latency. Agreed. Think about mod_perl - it's not just about 'faster CGIs'. Right now the 'integration' between tomcat and apache is in a very bad shape, the web server is used mostly as a proxy ( that adds a significant overhead, apache+tomcat can be slower than tomcat standalone), and to servle static files ( that are not password protected ). Authentication can be done only by tomcat, and having apache send messages to tomcat to authenticate for static pages would kill any performance. In many cases I've seen, apache isn't even being used to serve static content from the java webapps. OTOH, I think we could come up with a better way to map tomcat's static content to the virtual URI-space of apache to encourage this more. In general, tomcat can't benefit from most of the features the web server provides, and the web server can't benefit from any feature that tomcat provides. I have to disagree with this. In general I think we're all much more comfortable using apache-httpd's HTTP parsing routines, if not merely for the fact that they are tried and tested (not to mention, in many cases implemented by the spec author). Tomcat can and should take advantage of this. In addition, the huge collection of httpd modules can be of huge value to tomcat. The biggest problem I'm seeing here is integration. And the difference between a method call ( even via JNI ) and IPC - it's pretty significant. But that's nothing compared with the fact that via JNI you can avoid a lot of memcopy, use existing ( and optimized ) methods, have access to a powerfull API, hook deeply into apache. I agree that there is a potential bottleneck in remote IPC that can be avoided with things like JNI. However, I don't think that JNI has better access to the httpd internals than any other apache module. I would imagine request/response latency is reduced, but how well does it scale, and how does it deal with issues of robustness? It doesn't scale very well in a multi-process model, and it's as robust as the Java VM. The main problem with multi-process model is the sessions. But that can be resolved ( especially if you take advantage of mmap ), and you still gain a lot from the deep integration. Apache 2.0 will offer a few alternatives to the multi-process (aka prefork) model, two of which are multi-threaded, multi-process models. You may want to look into this (perhaps having one multithreaded JNI-wrapper per process). If anything, the newer models will give you many more variables to play with. The concern I have with robustness of the VM isn't the VM itself, but the 3rd party jars that are used in most webapps. One of those modules causes a segfault in the multiprocess model and apache/tomcat just keep on chugging. If you have a segfault in one of the multithreaded models, you end up losing all the threads in that process -- even if they are in the middle of a healthy connection. (Apache will have this same problem, so it's not specific to tomcat) -aaron
Re: cvs commit: jakarta-tomcat-connectors/webapp/lib wa_config.c
On Tue, Aug 21, 2001 at 04:24:37PM -, [EMAIL PROTECTED] wrote: pier01/08/21 09:24:37 Modified:webapp/lib wa_config.c Log: Allow web-applications to be deployed as root of virtual hosts. Thanks to Philipp Richter Philipp.Richter at CUBiT.at Cool! Would you mind posting a sample config to show how this special case works? (Just a snippet from httpd.conf, and the relevant pieces from server.xml) -aaron
Re: mod_webapp
Nope... The official _stable_ WARP code is distributed with Tomcat 4.0, and resides in that CVS... The one you download from jakarta-tomcat-connectors is the working copy... As soon as I tag a stable version, that gets copied over into the official repository... So we will need to explain this in the README.txt. If the idea is to have the developement version in jakarta-tomcat-connectors and the maintenance mode one in Tomcat 4.0 that is great! (Otherwise it is confusing...). Aaron is pro README. j-t-c could really use a STATUS file as well...i'll attach the boilerplate STATUS to give us something to work with. If will change apjava.m4, so that if you don't specify --with-jdk, you won't compile java (remove the compile task, and remove all dependancies) sometimes in the future... Now it's not a priority (the priority is to have that piece of shit to pass the watchdog tests, soo). Maybe next week. The CVS I have does not compile because apr_socket_create()... It misses the inherit parameter! APR has added it to the apr_socket_create(). Should I fix it or just tell we need a tagged APR (like APACHE_2_0_20). Actually hold off on this, I think the function params will go back to normal shortly... -aaron ---cut here Jakarta-Tomcat-Connectors STATUS: -*-text-*- Last modified at [$Date: $] This project exists to ... Release: RELEASE SHOWSTOPPERS: Other bugs that need fixing: Other features that need writing: Documentation that needs writing: * Documentation? What documentation? Available Patches: Open issues:
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Sat, Jul 07, 2001 at 05:11:04PM -0700, Pier Fumagalli wrote: Quoting Aaron Bannert [EMAIL PROTECTED]: d) jakarta-tomcat-connectors (* Pier is working on this, I've submitted Hold it... Pier is working on the new build for the WebApp Module, and the documentation related to it... I never said I'm going to take care of the documentation of all jakarta-tomcat-connectors :) :) :) Whoops, sorry. I knew that, but it slipped out. :) -aaron
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Sat, Jul 07, 2001 at 09:25:46AM -0700, Craig R. McClanahan wrote: Yes, we obviously need pointers in a top-level README on where the docs went. I'm willing to collaborate on these types of docs. On a slight tangent, I'd like to point out that we could use more STATUS and README documents, if only to serve the purpose of a signpost for current and new developers. *Every* CVS module that is a work-in-progress should have some sort of STATUS document, as well as a README describing what the repository contains. The first serves as a road map for any new developers who want to get into the source. The second serves as a roadmap for new builders/testers who want to know what the heck they're looking at. Also, on my list of high level desires, I forgot to include one: * All of the Tomcat documentation should be visible online at the Tomcat web site. which can (at least partially) deal with Alex's how do you set up the VCR issue :-). ( s/Alex/Aaron/ :) That will partially satisfy me, but not everyone has fully-connected high-speed internet access and graphical browsers (at least not while they're trying to get Tomcat working). I'd still like to push for plain text documentation for each of the following: 0) README and STATUS in each of a) jakarta-tomcat-4.0 b) jakarta-regexp c) jakarta-servletapi-4 d) jakarta-tomcat-connectors (* Pier is working on this, I've submitted the beginnings of a README) e) the various TC3.x repositories that I'm less familiar with 1) build instructions for each. Not extensive, just simple bootstrapping instructions, maybe even just in the README. 2) [basic] configuration instructions. Again, not extensive, but enough to get it up. Maybe a recipe that would answer questions like: a) What goes in server.xml? b) How do I start/stop TC? c) What must be already installed in order to run TC? (JDK version, etc...) Who's with me on this? I can submit an outline for each and let the people with more experience fill in the blanks. 2) Why have the docs as a web app? I'm not sure I see the benefits yet, aside from being able to have a pointer to the docs from the ROOT/index page. A couple of reasons: * Because we already do -- and it's quite convenient to be able to look at the docs once you get Tomcat started the first time. The problem today is that we are really overloading the ROOT web app, and it's not particularly well organized. I totally agree that it is convenient, but it may be harder for us to realize the difficulty in getting this beast rolling the first time from our altitude. We want every college student who has ever had any interest in Servlets/JSP running this thing on their home Linux/*BSD/WinXX (*gag*) machine, and they're only going to do that if the barrier to entry is well defined. -aaron
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS: [TomcatDocu mentation Redactors To Hire]
On Fri, Jul 06, 2001 at 10:06:21PM -0700, Craig R. McClanahan wrote: * Tomcat docs for a particular version should be delivered as one or more web apps (not necessarily the root webapp as is current practice). That way, the corresponding WAR files could be dropped into *any* container, or opened up and read directly from the filesystem. * At least two documentation webapps (developer-oriented and user-oriented) would seem to be appropriate. Having more than two will make it difficult to create reliable hyperlinks (since you don't have any control over the context path that someone uses to deploy). Although I find the rest of your comments on this topic both clear and refreshing, I'd like to point out a possible fallacy here: Providing Tomcat documentation in a WAR file is a little like providing a VHS tape on how to setup your VCR. It may seem really elegant to have on-the-fly style-generating documentation, and I may be alone on this, but I think that the majority of the user-oriented documentation should just be plain text. (By 'user-oriented documentation' I specifically mean build instructions and deployment configuration docs). Just my 2c, -aaron
Re: problem with mod_webapp
Hmm, I wonder if we should do a TR with APR to give a release that is separate from httpd-2.0. I don't see any reason why we couldn't do this. I just have no clue how to do the TR. My understanding is that anyone with commit privs can do that. I'll look into it though. BUT, I think that the precedent with the APR-using projects is to require a source checkout. Subversion and httpd-2.0 both require the current CVS version of APR. This allows APR to not have to maintain backward compatibility with previous releases (not that we would anyway). I think the only reason that works for httpd-2.0 and subversion is that they are heavily involved in APR development. We can't very well expect every project to be in that same boat. I like your first suggestion much better (tag-and-roll to get [semi]stable versions of APR pushed out, then projects that have problems can submit patches, etc...) And, I guess, my point is that we should start that transition now. Start to write a mod_jk that is built around APR. By the time that is done, Apache 2.0 may even be release candidate. Or not. What about working an APR wrapper ? ie something which wrap OS calls to APR or native calls ? And make mod_jk call wrapper functions ? I think that defeats the purpose of APR. If APR isn't doing it right, then APR needs to be fixed. APR should definitely support any platforms that you are concerned about (i.e. Win32, etc.). Which, of course, means that httpd-2.0 will run on those platforms as well. The idea is that APR would better support these platforms than rewriting the same code in mod_jk. And, ideally, if you build around APR, you will simplify the build process because APR will figure out all the OS trickiness for you. I completely agree. We don't want a wrapper to a wrapper, yuck! If APR isn't portable, then it's broken. But even APR will only cover OS calls, and didn't solve the problems of linking with web-server differents from Apache (IIS/iPlanet/Domino...) Correct, but the core jk components could still be built around APR. And, I imagine that the problem of other webservers has to do more with their specific OS than the web server (i.e. linking in APR). And, hopefully, I'll have time at some point to actually back up what I am saying with code. I've just got a bazillion other things on my plate right now. =) -- justin aka APR evangelist -aaron
Re: problem with mod_webapp
On Thu, Jun 28, 2001 at 06:35:29PM -0700, Justin Erenkrantz wrote: What if (random thoughts coming out now), instead of requiring people to build APR (since that seems the biggest source of problems), we don't simply ask them where the tarball is, and then in our configure script, we configure it, and then build it together while building the module... In that way we won't have troubles with previous APR installations/builds, we _know_ what we're going to supply to the APR configure script and we solve all those troubles? Yup, that's what httpd-2.0 does. Just require them to slap the apr sources in srclib (or something like that). APR isn't standalone just yet. I was shocked when I saw that mod_webapp required an install of APR. =) -- justin APR *will* be standalone, but since it is not yet completely stable it may at random times not be standalone. That may be unsatisfactory for j-t-c, or maybe that just means that we have to work harder to get APR to be standalone. Last time I built APR standalone for use with j-t-c I didn't have a problem with it (on Solaris 8/sparc and Linux/RH 7.1/x86). We just have to have docs that capture all the scenarios (which is much harder to do in scripts). Maybe I can post some doc updates from my experiences building that beast. -aaron
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Wed, Jun 20, 2001 at 09:41:19AM +0200, jean-frederic clere wrote: Aaron Bannert wrote: [snip] Apache Tomcat Connectors [snip] Installing Apache Tomcat Connectors === [ This could use some serious work. There are a few factors that make this more complicated than it should be, namely using 'jk' vs 'webapp', and then how to install and configure for both TC 3.3 and TC 4.0. ] That is not easy. I am thinking of adding the logic for a make install for the native part but what about the jar files and server.xml? Any hints? I am merely trying to beef up the j-t-c documentation. I think it would be best to simply include instructions for installing and configuring each of the various j-t-c connectors (jk and webapp) in both the major tc branches (3.3 and 4.0), rather than trying to script everything. What are you looking for with the jar files and server.xml? I have some issues with the various jk/native/apache-1.3/build-xxx.sh scripts, mostly that they make many assumptions about your apache configuration, and then they go in and modify your httpd.conf. As long as there are some accurate instructions and we aren't forcing people to use these invasive build-xxx.sh scripts then I'm happy. -aaron
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_md5.c
On Tue, Jun 19, 2001 at 03:55:09PM -, [EMAIL PROTECTED] wrote: hgomez 01/06/19 08:55:08 Modified:jk/native/common jk_md5.c Log: Bug fixes, bad buffer used ! Revision ChangesPath 1.5 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_md5.c [...] ISTR that j-t-c/jk/native already depends on APR. Instead of duplicating efforts, may I suggest we reuse the md5 functionality of APR (see apr_md5.h)? -aaron
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Tue, Jun 19, 2001 at 06:16:15PM +0200, Gomez Henri wrote: I've been lurking on this list for awhile and wading through all the code, and this one has been bothering me for awhile. Is there a way we could get a STATUS and README file written for j-t-c? I would do it myself, but honestly I'm at a loss for what would go in there. Hi Aaron, What did you need exactly ? in jtc you'll find 4 subdirs : coyote: a reflexion framework +/- on what is needed to handle HTTP request on the java side. jk: the mod_jk native and java parts. There's build files (build.xml) for both TC 4.0 and TC 3.3. Also the build configure for the native part (jk) is really easy to use (just read jk/native/README.configure). util: a set of API used by Tomcat. There came from Tomcat 3.3 but they were extracted since and put here. webapp: mod_webapp/warp protocol (only ajp14) Thank you for the details, they were very useful. I have put them together with some other things I found scattered around in code and various other places and compiled a README.txt that someone may wish to commit. It needs some work in places where I am unfamiliar, but it gives us a good place to work from. -aaron Apache Tomcat Connectors Introduction This CVS module contains the code for the Tomcat Connectors. It currently contains two distinct connectors: jk and webapp. This module also contains utility classes that are used by the connectors as well as Tomcat itself. The components are: Connectors -- * jk: The native and java parts of the ajp12/ajp13 [is this correct?] connector. Both Tomcat 4.0 and Tomcat 3.3 are supported. * webapp: The native and java parts of the ajp14 connector, now known as mod_webapp and warp respectively. Utilities - * coyote: A reflexion framework +/- of what is needed to handle HTTP requests in Tomcat (in java). These utilities are not intended for user code. They are used internally by Tomcat. * util: A set of APIs used by Tomcat. Note: these came from Tomcat 3.3 but they were extracted for general use here. Building Apache Tomcat Connectors = It is not necessary to build and install both connectors. [ Talk about tradeoffs between jk and webapp. Perhaps reference some other documentation that already does this. ] * If you wish to build the 'jk' connector, see the documentation in jk/README.txt for the java implementation, and jk/native/README.configure for help with the native Apache module. * If you wish to build the 'webapp' connector, see the documentation in webapp/README.txt. Installing Apache Tomcat Connectors === [ This could use some serious work. There are a few factors that make this more complicated than it should be, namely using 'jk' vs 'webapp', and then how to install and configure for both TC 3.3 and TC 4.0. ]
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Tue, Jun 19, 2001 at 10:06:07AM -0700, Aaron Bannert wrote: Apache Tomcat Connectors Introduction This CVS module contains the code for the Tomcat Connectors. It currently contains two distinct connectors: jk and webapp. This module also contains utility classes that are used by the connectors as well as Tomcat itself. The components are: Connectors -- * jk: The native and java parts of the ajp12/ajp13 [is this correct?] connector. Both Tomcat 4.0 and Tomcat 3.3 are supported. * webapp: The native and java parts of the ajp14 connector, now known as mod_webapp and warp respectively. Whoops, that's obviously not correct. warp is the protocol (right?), mod_webapp is the webserver module (Apache et al), and do we have a name for the java part? How about this instead: * webapp: The native and java parts of the connector that implements the warp protocol (ajp14). This includes mod_webapp for integration with a frontend webserver (like Apache). -aaron
Re: [tomcat-dev] [J-T-C] What about ajp13 refactory in java ?
On Mon, Jun 18, 2001 at 05:01:59PM +0200, GOMEZ Henri wrote: I'd like to know what's the current status of ajp java on j-t-c. I've been lurking on this list for awhile and wading through all the code, and this one has been bothering me for awhile. Is there a way we could get a STATUS and README file written for j-t-c? I would do it myself, but honestly I'm at a loss for what would go in there. -aaron
