On Tue, 7 May 2002, jean-frederic clere wrote: > > 1) What about moving scripts from jk/native to > > just jk ? It avoid duplicate between native > > and native2. > > That may bring problems: the configure.in normaly contains the files you want to > generate.
IMHO autoconf is justified only for jk2/apache1.3 ( eventually ). But if we decide to use it for apache2 and jni - then probably that may be a good idea. > > 2) What should be done for APR in Apache 1.3 ? > > Should we use external shared apr lib ? > > That is probably the best. Building mod_jk without APR is another option here. ( i.e. only with socket and what was in jk1 ). If we use apr, I think ( a bit strongly ) that we should use exactly the same library as apache2 does. APR libs should/could be installed in /usr/lib, /usr/include, and considered 'system' ( like glib, qt, nspr, etc ). If you build a non-threaded version, it shouldn't be called libapr.so in any case. Also I think the version that comes with Apache2's binary is to be considered the 'reference' - since Apr was not released independently, the apache2 package can be considered as the 'dependency'. > > Should we use static build apr (like does webapp) ? > > In all case should the apr for 1.3 must be with > > or without pthread ? Static apr may be a workaround, but I would avoid that if possible. libapr.so should be a 'deterministic' entity, if someone has a problem we should know he uses a certain version. > > 4) What about jni support ? > > > > Costin is the one that knows. It should use libapr.so, the one from Apache2 preferably. libjkjni.so should be generated - it won't be used from apache, but from java, and the same version of libjkjni can be used with any server ( apacheX, iis, etc ). In other words - you only compile libjkjni with Apache2 and APR, that's what java will use in all cases. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
